Thinking Out Loud - The Pain of Developing Bad Ideas

The problem with XUL & XMLHttpRequest is that XMLHttpRequest is not well suited to the transmission of server-side objects to the client-side ones. JPSpan fails miserably at what it does because of the lack of implicit sessions, the complexity involved, and the lack of queing and threading on the client side. This is no fault of the developers, they've done a great job at implementing a bad idea - and it seemed so right initially.

What we need is a language neutral intermediate data format. XML you say. Too easy. But the differences between Javascript and PHP clash far too much that though a PHP object goes into XML, a different, far more crippled object comes out in Javascript.

Both PHP and Javascript are all about doing one thing at a time. But Firefox has problems that interfere with the UI if you try to do synchronus XmlHTTPRequest connections, so you have to step into the world of Asynchronus connections. This is where the problems get worse. Callback functions. JPSpan relies on anonymous functions in callback handler varibles. Thus, you can't go: var mySale = new Sale(); alert(mySale.getTotal());. You have to rely on a function in two parts:

var handler = {
 getTotal: function(result) {
alert(result);
 }
}

function sell() {
var s = new Sale(handler);
s.getTotal();
//there is no way in this function to get the result,
//without resorting to global varibles.
}

That's incredibly more intricate than:

function sell() {
var s = new Sale(handler);
alert(s.getTotal());
}

Which is what we know and expect.

So, how do other AJAX applications manage broking objects where I'm failing?

Google's Gmail uses a UI engine which speaks javascript as the intermediate language. The server spits out javascript objects, there's no intermediate XML which makes us lose information in translation.

More 'traditional' web services (as this is all that we are really trying) do fine with RESTful interfaces and spitting XML at each other. There's a controlled and defined vocabulary, the server does their own thing, spits it out in hardcoded XML, and lets the client deal with the mess. This was the path I first started on, and I ditched it because when it got down to it, I was trying to pass strings about as my messages - messy, and I needed to pass more than one bit of information at a time.

PHP automagically understands GET and POST form submissions. XML via GET/POST as a restful service (ala musicbrainz) is an extra layer of abstraction ontop of that - but one we can deal with at the cost of losing our automagic varible parsing.

After writing this post, which was to entirely rethink the problem and forget that I'm screwing up quickly, I've realised that JPSpan isn't the way - the ideas are right, the implementation is too tangled. XUL, XMLHttpRequest, REST, XML. Well defined and controlled spec to start from. Evolves to meet real world implementations.

I recall initially I wanted RDF/XML over REST, but I abandoned this because RDF parsers in javascript where either closed to me (firefox security prevents me using the internal one) or not fully implemented (sorry Jim :/). How about RDF/XML over REST, parsed as XML by the client application, but more stable clients (like java ones!) could use RDF/XML to conduct transactions? I think I like that idea.

Next stop: Square One.