I'm really starting to like where the Dojo project is going... Here's where they have all of their unit tests (running against the nightly build).

Lately, I've been spending my free time thinking about how to deal with the situation that our platform has found itself in. We make pretty heavy use of the "web remoting" design pattern, with each of the calls taking a different length of time to return and each having a different relative priority over the others. Additionally, I've been considering how to add some of the type-ahead functionality that Google Suggest has been implementing (more on that in a bit). Our remoting requests cover the a wide spectrum of models: posting changes to the server that take anywhere from 1 to 30 seconds to complete; retrieving small bits of data that take short periods to return; or running advanced searches against large data sets.

Each of these different interactions with the server occur within the same context, and in some cases users may be expecting the page to be able to continue to function through out the processing of one of the long running requests... Then we hit the HTTP 1.1 specification's limitation (check out section 8.1.4) on the number of connections that may be established between a client and a server. That's right folks, everything needed to make a page work MUST (to use the notational approach of the RFC authoring class) be fit into no more than 2 persistent connections between the systems. This is one of those rules in the specification where I wish the browser makers had chosen to ignore the RFC, although I'm sure that there is a perfectly valid rationale around the limit. The fundamental problem that I have right now, is that I can't figure out how to make the Microsoft.XMLHTTP object do what is suggested earlier in the specification - pipeline (that bit's in 8.1.2.2).

Moving on from the pipeline issue, I've been attempting to come up with a methodology that allows us as developers to tell our XmlHTTP wrapper objects what priority each request should be set to, what the timeout should be for the request, and if the request can be canceled by the calling code or by the wrapper objects if higher priority requests need one of the two connections. This is a bit of an entertaining dilemma to think through, as it is bound to have implications on the way that we model our requests and implement the functionality.

Here are a couple of links that I have been collecting on the topic:
Async Requests over an Unreliable Network
Tuning AJAX
LiveSearch Paper Mountain's Livesearch Fun

I've been playing with the Blogger.com mobile phone blog capability (pretty great stuff), and decided to link the "mobile blog" to this blog. So, here's the first entry. I've been quite again on this page, but that's because I've been at the office WAY too much recently. Anyway, this is the view from my office window. I'll only have it for another couple of weeks, because my group is headed back to our main office downtown (now that there is actually enough space).

It's a nice view... I'm going to miss it.