I am switching over to a new hosting service. Let's see how it goes.

I picked up a copy of Agile Documentation today. I have been tempted to buy it in the past based on the table of contents, but the title is so buzzwordy, that I had passed on it previously. So far, so good.

I have been using XMLHttpRequest at work on an internal tool. It is very fast and handy. One system, that I could see developing out of this, is a generic message bus. Instead of having each UI element check for changes back on the server, it would be nice if they could register interest and only request new data when they are told of a change. Perhaps a callback function would be passed in when registering. The next question is how stateful is this bus? Can it work across all user's regardless of the state, or does some state need to be maintained, such as which messages have they received. Should this state be maintained client or server side?

The client side bus piece would be the one item frequently polling the server side application. Upon a change, an object could notify it's listeners that there was a change. A unique change id would be created. During the next X amount of time, whenever polled, it would include a very brief change element such as <change id="uniqueid" model="testMatrices">. This timed method removes a per client state, but will fail for connections that are slower than this X time threshold.

The first time a client polls and gets this data, it would cache the id and then call the registered functions for testMatrices, such as reloading data from a listMatrices resource. Subsequent polls where testMatrices had changed could be ingnored until a new id attribute value is encountered.

When considering the XMLHttpRequest payload, there are three obvious routes to consider.

1. responseXML -> pure data encoded in XML


2. responseXML -> pre-formatted html


3. responseText -> pure data encoded in JavaScript

Option 1 is attractive, as you can write the resource in a client agnostic way. The input and output communicate the current data in a known format. A fat Desktop client, or our web app can processes this in the usual manner.

Option 2 is probably the easiest to implement for simple cases. Once we have our response, we can just traverse our current web document and replace nodes with the same id. The downside is that our server side resource has to keep track of the presentation issues.

Option 3 is strikes a nice balance between reducing the time for client side development, client side XML processing, and server side stateful processing. Our resource will need to know how to marshall data into JavaScript variable definitions, but if the resource only services a single known application, then this may be a very effective route. Once the responseText is evaluated into live JavaScript objects, then they can inspect the old data and make updates accordingly. Then the elements can redraw themselves on the page.

Just to torture myself, I think I will start with Option 1 for a side work project I am doing.

It seems that keeping statefullness on the client side in the browsers memory is a trend we are heading towards. XMLHttpRequest allows us to load the UI of a web application and then create, read, update, and delete information from the server without reloading this initial shell. Many of these types of new applications actually version the application resources that are download, since you can't assume your user will reload the application with each click. When code is pushed out on the server side, a reload can be triggered to the user's UI resources and frontend scripts. Developers should start profiling browser memory usage, as these long running pages without a refresh could become bloated hogs without careful regard to memory allocation. Once data is no longer being used, it should be removed or nulled out from any in memory collections for example. It is interesting to think about how this new tool can change development concerns and abilities.

There is a weird tension between desktop applications and web applications.
Between locally stored documents and invisible data squirreled away in a off-site service.
Many of the applications that I love to use, like del.icio.us, Wiki, or Flickr are fantastical available from any computer, but at the same time, Sometimes I want a private local copy of them, stored in a data format that I can version, combined, and migrate as I see fit.

Google Desktop is a great example of capturing this tension. I can search over my computer's private corporate data. I want to use a local private secure del.icio.us to bookmark all of my internal URLs at work. I want a Flickr sitting on my desktop that manages the thousands of photos before publishing out the top 100 to the world.

Google Desktop points in the right direction by providing a layered approach, making both Web and Desktop search results available. Local web services should be visually distinct, but seamlessly offer remote web services at the same time. The web is great for sharing public information. The net is great for synchronizing computers. Computers are the private islands we live in rich with artifacts and influences that are part of the process, but aren't part of the public product.

Perhaps a missing component of the Web OS, is a standardized locally installed web application server. This component could host war (Java), php, ruby, lisp, etc applications. Keeping services requirements low is possible, because these services will be locally. Programmers should consider using existing file formats and embedded databases as much as possible. MySQL and Oracle would be overkill for most local web apps.

Perhaps this is infrastructure is too much, as many applications today simply embed a simple web server in their desktop products already. It may well become a tendency of programming platforms to provide a web application server component as part of the base language, so that a user who as installed the runtime, will be able to host your local web app. Currently these libraries are usually add-on's such as Jetty or Webrick.

It is great that Google has not only provided the best general search on the WWW, but that they also have now offered us a local application. For sites ( like Google ) who are embracing web service APIs we don't have to wait for the WWW site to build the local web app. With plug-ins to existing fat clients, we can get the local get a taste of the local + remote web app. I have just started using iPhoto + FlickrExport to upload to Flickr and it is fantastic, but this is only the file export piece of the puzzle. I want to run something like Oraganizr on my thousands of photos. I want changes written out to my drive.

From cubeland to U shaped office. Moving on up in 2005. This is my first real office, so it is kind of exciting for me.

Proposed Best Software Essays of 2004