Optimizing this blog for easy reading on an iPhone turned out to involve some hacking. It did not take much time to implement, but within the constraints of static HTML pages, I had to combine a couple of tricks to make, firstly, the pages more readable on the iPhone screen, and secondly, to make the pages load faster by cutting down the number of resources downloaded over the poor AT&T Edge network. The solution required using a combination of the user-agent string and CSS3.

The script tag is often used to bypass the same-origin security policy of browsers, and communicate with sites belonging to other domains. In essence, a web page hosted on www.foo.com could use this technique to send a request to www.bar.com using some JavaScript. Some Ajax frameworks offer transport layers that use this technique for cross-domain requests. The Dojo framework has had one for a long time. There is one for the Prototype framework now. There is nothing wrong with the technique employed, but whenever I see it mentioned as a "pluggable" transport layer in Ajax frameworks, alarm bells start ringing in my mind. While being an interesting technique, it is not safe, it is not HTTP friendly, and it must be used with care.

Over at Ajaxian, there is a post written about reinventing XMLXttpRequest. This so-called corss-browser implementation is nothing but a wrapped XMLHttpRequest object, which is implemented in JavaScript with some of the methods wrapped partially to do some interesting things. The code is posted at http://code.google.com/p/xmlhttprequest. While at BEA, I took a similar approach for letting aggregation frameworks (such as portals) manage XMLHttpRequests between browsers and web applications (such as portlets). The approach turned out to be successful. It allowed portlets use a wrapped XMLHttpRequest directly or via Ajax frameworks such as Dojo in a loose-coupled manner. Some "security experts" also called wrapping XMLHttpRequest a security risk!

However, due to the way the XMLHttpRequest is currently drafted and how it is implemented in browsers, making such wrapped implementations conform to the XMLHttpRequest specification is impossible unless the wrapped object is implemented natively and not in JavaScript. Here is why.

In my previous post, I discussed the key problems in using XMLHttpRequest within portlets and other similar widget-style components. The programming model used for XMLHttpRequest interferes with the way portals aggregate pages, and provide other features like inter-portlet events, state management etc. In this post, I would like to discuss the script interface XMLPortletRequest. Before we begin, note that, although I am describing this interface in the context of portals, the idea of a wrapper interface such as XMLPortletRequest over XMLHttpRequest can be used to solve a number of use cases related to widgets and browser-side components. I will discuss more about those possibilities in a later post.

Starting with this post, I would like to describe a new script interface called XMLPortletRequest. The intent of this interface is to provide a means for portlets to implement asynchronous and/or partial page updates within the portal/portlet paradigm, and yet remain compatible with Ajax toolkits and portlet bridges (JSF, Struts, Spring MVC etc.). I developed this approach several months ago, and the portlet-related specification groups, viz., JSR-286 in the Java-land, and WSRP in the language-agnostic web services land, are actively considering this interface as the basis for building Ajax-related solutions. Some specifics of this model are still being debated in these groups, but the semantics of the model are more or less finalized. Please read on for some background and details.

There is a paper titled Subverting Ajax (PDF), by Stefano Di Paola and Giorgio Fedon circulating the web over the weekend. This paper claims that, by using XMLHttpRequest, an attacker could “inject client side code to toally subvert the communication flow between the client and the server”. This paper also talks how some previously known attacks like cache poisoning, frame injection etc. See below for a quick demo of what the authors of this paper are talking about. The demo makes me conclude that the so-called subversion is hyped up, and does not actually pose a new security threat.

The discussion at Dare Obasanjo's blog, and the references to some other recent posts motivate me to look at some of the broader arguments being made. It is clear that processing JSON data using JavaScript is trivial, and that is what makes JSON a popular alternative over XML currently. All other advantages and disadvantages over XML are incidental. If we take out JavaScript from the picture, JSON is not a clear winner. Both JSON and XML take some effort to parse and process outside JavaScript.

Last week, Opera posted a blog entry describing a different style of doing server push. The technique described is based on server side DOM events as currently proposed in the WHATWG Web Applications 1.0 specification. Also check out the demo, which is based on an early and partial implementation of server side events in Opera 9.x. The approach described can be used to send events over long-running connections to the browser, and in someways resembles the onload event handler of the XMLHttpRequest as implemented in Firefox. But there are some key differences between these approaches.

What is the right response format for XMLHttpRequest in Ajax applications? The answer is simple for most markup-oriented applications - use HTML. For data-oriented applications the choice is between XML and JSON. Until recently I did not pay much attention to the question of whether to use XML or JSON. I just presumed that the use case at hand will dictate the format. I had a chance to test this presumption recently. In this post, I would like to describe the criteria I used for comparing between XML and JSON, and my analysis.

This may sound like a dumb question to ask. But I find that Ajax toolkits offer a mixed bag of features not all of which are necessarily related to "asynchronous JavaScript and XML". Things usually found in a toolkit include - basic I/O support using XMLHttpRequest and/or iframes, client side widgets for partial page updates, server side controls/APIs for partial page updates, eye candy like drag-and-drop, scrollbars, sortable tables, layouts etc, or support for data transfer via JSON, XML etc, or Comet and so on. I feel that when Ajax toolkits come up for discussion, it is difficult to have a meaningful conversation unless there is a clear set of goals and use cases, and which aspects of Ajax toolkits are we talking about.

I was curious to see how well latest versions of Firefox (1.5.x), Internet Explorer (6.0.x) and Opera (9.0) support the current working draft of XMLHttpRequest (http://www.w3.org/TR/XMLHttpRequest/), and spent the weekend to write some tests to check conformance. Since the XMLHttpRequest specification is only trying to standardize what was already supported in browsers (and promote interoperability), these tests can not really be used to rate current browser support. I would have liked to see the current draft reflect what is already supported by the current browsers, but it turned out to be not the case. There are some key differences between what is supported in browsers, and what the current draft specifies.

There are two solutions that are being used to provide some amount of back and forward button support for AJAX based apps. Both these involve someway of changing the URI as seen by the browser. That is because, current browsers manage cached pages against URIs (one per URI per frame). The trick is to change the URI without leaving the current page. I find that both the solutions are lacking the kind of flexibility and behavior one would expect from browser navigation controls (i.e., back, forward, and reload buttons).

Ever wonder why the method getElementById returns null when applied to responseXML of XMLHttpRequest?

Thomas Rabaix discusses about this problem briefly in his Issues when developing AJAX Libraries. Here is a more detailed answer.

Is there such a thing as a server push over HTTP? The short answer is no. The long answer is that you can emulate sever push over HTTP and create an illusion to the user that the server is able to push data to the browser as and when new data is available on the server side. In this post I would like to give a quick demo on how this can be done using XMLHttpRequest. Note that server push like this has some pitfalls and you need to carefully design a protocol for creating and maintaining connections, and need a scalable server.

[Click here to jump the demo.]

Every other web developer that I talk to is trying to figure out how best to use Ajax in their apps either to provide some slickness to web apps, or to avoid total page refreshes. In most cases, writing the server side processing code is trivial. You can use JSPs, servlets, struts, JSF or whatever to process Ajax request, and return data (as XML) or markup (as HTML) fragments. Writing client side scripts is where all the fun is. But when it comes to portlets, server side processing for Ajax requests gets tricky. Portlet related standards like JSR168 and WSRP 1.0 do have some limitations in supporting server-side processing of Ajax requests. These specs leave out a few details that limit the use of portlets to process Ajax requests and return data or markup. Read on, if you are interested in finding out what works, what does not and why.

A lot has been written about caching issues with XMLHttpRequest based apps. There is certainly some amount of frustration and confusion about this topic. I had the same kind of experience when I updated my blog recently to show a paginated blog entry list via an XMLHttpRequest. I noticed that mainstream browsers behave inconsistently when it comes to caching.