Here is a nice post at dev.opera.com. But I can't completely agree with the statement that

That's one side of the story. The other side is repeating the same ideas with better and more flexible technology.

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.

At BEA, we recently released a patch for WebLogic Portal 10.0 to support the XMLPortletRequest interface as an alternative to using XMLHttpRequest with portlets. See Ajaxifying Portlets - Part 1: Unmanaged Ajax and Ajaxifying Portlets - Part 2: Managed Ajax for more info.

Early this year I have blogged about the problems related to portlets using Ajax to update their UI from the client side, and my attempts at addressing those. See here and here. As I mentioned in those posts, I also tried to make the model a part of the JSR-286 API. Here is an update of where things stand now.

One of the questions I hear often is which Ajax framework to choose for building ajax-enabled apps. One way to answer this question is by comparing and contrasting - see which framework offers what kind of features, and compare those among various frameworks. That is an easy approach. But I'm beginning to realize that this is not necessarily the best approach towards selecting a framework. I think a more important criterion is how well a given framework can deal with heterogeneity.

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.

If you one of those developers that don't care much about JavaScript, CSS and the like, and do write code related to the web, you are going to disagree with what I am about to say in this post.

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.

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.]

Why not try some wordsmithing on a weekend? Let me start with this comment made recently elsewhere (keeping it anonymous to save myself from getting sued).