Articles tagged in ajax

  1. COWS not much an Ajax

    Saw it on Slashdot yesterday, where COWS Ajax was introduced. What is COWS first of all:

    Ajax has been revolutionizing the web. However it is greatly limited by the browser same-origin policy, meaning that your site can only be as good as the web applications and tools that you create. But there's a lot of great tools out there, wouldn't it be nice to tap into them? Changeable Origin Web Services -- COWS -- Ajax breaks down this barrier.

    It argues that "traditionally" Ajax, which utilises XmlHttpRequest object to perform asynchronised HTTP requests, has one problem -- which was actually a security policy. The way to solve this "problem" is by using its COWS Ajax mechanism which allows web services from hosts other than the origin of the page to be performed.

    Behind the scene is actually quite simple. In order to invoke a web service on a different domain, the COWS API does:

    1. Create a <SCRIPT/> DOM element.
    2. Point the src attribute to a remote Javascript.
    3. Append the <SCRIPT/> DOM element to <HEAD/>.
    4. Javascript code returned from a remote domain will then call a predefined handler, and then remove the <SCRIPT/> from <HEAD/>.

    Sounds exactly like how many complicated bookmarklets work. My old Google video download script works the same way. Besides security issues due to trust, there is really nothing new. In fact, I won't even consider it as "Ajax". What is Ajax then?

    In Ajax applications, you hand in your handler to be called back when the HTTP request completes. In COWS, there is no guarantee that your callback will be called. A Javascript file is returned by remote service and is evaluated by the browser, and at its mercy your response callback might be called. Your error callback is only called by constantly polling the system.
    Well, it is in Javascript and I won't argue that.
    The result of the web service is not XML. Nor JSON. In fact it is full on Javascript code that will be evaluated by your browser before the evaluated code calls your handler.

    I personally don't think COWS has resolved any issue that has already been addressed. Nor is it a savour to Ajax -- it is far more limiting than the "traditional" XmlHttpRequest style Ajax. There is however much market-speak on COWS' website:

    And in exchange for making the cool apps, the application host can create branding, drive traffic, or employ serveral revenue streams. Everyone wins! In this case, the cow coming home is the cash cow ;-)

    You need much much more than COWS to create a cool app, and you need much much more than a cool app to bring in the cash. Meanwhile, COWS just sounds like bull to me.

  2. AjaxTerm -- terminal emulation over the web

    Who cares about Web 2.0, as I have just found the single most useful Ajax application of all time -- AjaxTerm, powered by QWeb the Python web framework. From its own description:

    Ajaxterm is a web based terminal. It was totally inspired and works almost exactly like Anyterm except it's much more easy to install.

    It is easy to install (download, untar, run!) and its terminal support looks pretty good to me. Unlike Anyterm, nothing to compile, no external library to install (except Python), no Apache to mess up with (none of my servers are running Apache) and it is far easier to deploy. To hide behind a "proper" HTTP server, just proxy it with appropriate authentication.

    It can provide you a shell over HTTP/HTTPS, bypassing draconian firewall rules (like most corporate firewalls). The terminal emulation is actually quite good, and I have no issue running many terminal apps that I frequently used (w3m, vim, mutt, etc).

    AjaxTerm running w3m

    I am surfing Slashdot in w3m, running inside AjaxTerm inside Firefox 1.5 :)

  3. Google Reader, the Ajaxified RSS Aggregator in Beta

    Via Slashdot, Google has a new "Web 2.0" application pre-released to the public -- Google Reader beta, a heavily Ajaxified RSS reader, in the field against other popular aggregators like Bloglines or Rojo.

    Google Reader

    It has a nice very-Gmail-like interface, with short-cut keys like j for next unread message, and k for the previous one! Must have been a vi user! I also like the "page-less" scroller. While not as good as OpenRico's LiveGrid widget, it has demonstrated how web applications will be in the future -- no more "next" and "previous" pages, but a scroller that fetches new items on demand.

    However, the overall feel is still "beta" quality, and this beta is even more "beta" than Gmail's beta. It does not feel very responsive most of the time -- probably because I imported almost 100 feeds from my Bloglines account to give it a stress test. Lots of clicks are required to manage subscription, and I have not found a way to mark everything in a feed as read.

    Nor has it got any API, unlike Bloglines, which I have previously used to develop some applications. Won't take them long though, as Google has usually been developer friendly.

    It is promising though, and I hope it can evolve and improve in the same way how Gmail improved over the last year. Then it would be the moment where I'll dump Bloglines for this new Google service.

    And it should not be surprising that Google developed their own RSS reader. Since they have already fetched all the news feeds out there for the Google Blog Search to index, they might as well build a reader on top of the same data. Moreover, Google can conveniently slap in their AdSense for feeds to generate more income from advertisement.

    Now we just need to wait for it to mature.

  4. AJAX makes Application Server Redundant?

    Phil Wainewright wrote an article in ZDNet with an catchy title, How AJAX kills the application server. He said, An unnoticed side-effect of implementing rich internet application platforms -- whether they're AJAX or anything else -- is that this 'client-service' architecture eliminates the need for an application server to connect the Web …