Dave Johnson

There has been a flury of activity over at Ajaxian [1] regarding the asynchronicity of Ajax and Nick Lothian�s [2] two ideas for dealing with it. Nick�s initial ideas were 1) locking the view and 2) sending view state data with all requests [3]. The first idea certainly applies in some special cases but the second is closer to a general solution I think.

One of the comments on Ajaxian from Matt pretty much sums it up though and goes something like �yes well asynch programming is nothing new � it is used in swing apps [and many others] all the time�; this was the first thought that I had when I saw the headline in my rss reader. So here are my thoughts.

Building on Nick�s second idea, I think that rather than sending ALL the view state data to the server it makes sense to �store� the view state on the client (ie leave it alone) and create a unique identifier that is sent with each request and returns with the response. This keeps the request / response less complicated and less bloated. Now on the client it is a simple task to determine what data is for what request and perform the appropriate action. Furthermore, you can keep track of the timing of the requests. In the case of Nick�s Ajax tree control, one may come across a situation where a response has not returned from the server after clicking on a tree node (it may take a long time because of many child nodes say) and the user eagerly clicks on another node in the tree. If the second node click request gets back before the first the client has to decide which request has precedence. The client can look up the request time stamp and see that there was a previous TreeNodeClick event which is still waiting for a response. As I see it there are three main paths to choose from:

1) Let the events go at their own pace (if the requests don�t change the same area of the view then who cares)
2) Cancel the second quicker event (slow down tiger lets see what is in this first node you clicked)
3) Cancel the first slow event and move on (obviously if they clicked somewhere else they don�t care about the first)
4) Keep track of all response data and queue the response from the quick server request to occur after the slow request returns (aye that�s the rub)

Ok that�s four. Given these four options one can make up rules to decide which route to take. For example, given two events such as TreeNodeClick and TreeClose, the later event should of course take precedence and have other evets cancelled. In the end it boils down to the idea that, depending on the situation, asynchronous data requests should be able to cancel, block or ignore each other.

What I see as the hard part about the A in Ajax is understanding how the data from various requests may change the view on the client and their dependencies. This can certainly be onerous for the developer but the end result is a responsive and intuitive web based user-interface.

[1] Ben/Dion and Dion�s/Ben�s AJaX Mission
[2] BadMagicNumber
[3] BadMagicNumber - AJAX: Best Practice for Asynchronous JavaScript

Del.icio.us

This entry was posted on Friday, July 15th, 2005 at 11:04 am and is filed under Web2.0, AJAX, JavaScript, XML. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.