Infrequently Noted

I love my Mac. I really can't imagine going back to windows or even Linux for my desktop at this point. But I've got a beef w/ the speed of this sleek little box that I spend the majority of my waking hours in front of. It's kind of a dog.

I recently put another gig of ram into it, which has kept it from the infernal swapping, but for straight-up development work, it's just not enough any more. I'd drop the cash on a new laptop today if Apple was selling something half-again as fast, but they aren't. The clock speed increases aren't fooling anyone. I need something that feels as fast as the thinkpads my friends are starting to tote around in lieu of their PowerBooks.

So c'mon Apple. Get it together so I can spend money with you again.

This week, Dojo will be releasing our first full public version, 0.1. It's not "fully baked" in a lot of ways, many things will change as we go into 0.2, and we already have a ton of things slated for past that, but 0.1 will be the best DHTML toolkit I've ever helped to build.

We've already started documenting some of the major parts of the system, and we'll continue that after 0.1 flys the coop. There's some really amazing stuff in there...can you say stable, lightweight, cross-platform WYSIWYG?

I spent most of the day yesterday in Palo Alto at barcamp. The talks were great, the quality of people who have shown up is mind-blowing for a less than a week of organization. Big shout out to Chris for getting the whole thing put together.

Of note from yesterday were Ping's talk on anti-phishing techniques and the morning discussions about user-generated content; a discussion which turned to user-created content of almost every form.

I expect I'll be going back this afternoon to catch the tail end of things.

I feel truly lucky to live in a place where I can attend such things on a whim.

The Mozilla Foundatio...er...Corporation has released Alpha 2 of the next release of Firefox, and there's a lot of good stuff in it. On the whole, it feels faster, and tons of exciting stuff has already landed in this release.

Aside from E4X, it's hard to see how Deer Park is going to make my life much better as a DHTML developer, though. The story on rich-text editing is still grim. <canvas> is a disaster whose impact is only lessened by the inclusion of a minimal SVG subset. The platform is overall improving, but XUL apps still require enduring an RDF mind-fuck in order to get off the ground. Overall, you get the feeling that Deer Park is 2 steps sideways, one step forward.

But it wouldn't take much to change that from the perspective of the DHTML, nee, "Ajax" developer. Here are a couple of simple-ish things that would make our lives immeasurably better:

1. Local string caching from script
   
   This is a strange name for a very very powerful capability: caching. Webdevs today need a coherent, simple, and workable local cache which can be accessed form script like any other object/hash and which stores only strings. Such a cache needs only a couple of properties to be wildly successful. Firstly, use the exact same-domain policy as cookies currently are subject to. Secondly, tell me (from script) how big the cache is and how much space is still free. Thirdly, let us specify expiry and flushing policies for it from script (not via HTTP headers). But please, whatever you do, do NOT over-think this problem.
2. Event-transparency in the z-order and positioned event generation
   
   Allow developers to specify that a particular DOM node is "transparent" to DOM events. Which is to say, it passes them "down" the z-index stack without triggering a dispatch or bubble sequence in any way. This should probably be handled by a "-moz-" prefixed CSS attribute. Related to this, let us generate DOM events at a set of coordinates without knowing ahead of time what the node we want to route the event to happens to be. Both of these capabilities are amazingly important for a whole set of graphical apps that Deer Park is about to make available.
3. Improve Venkman's profiling output
   
   Venkman is the most powerful tool in the professional DHTML developer's toolkit today, but it's crippled when it comes to outputting useful data from it's profiling tool. Either try harder to assign names to anonymous functions or at least make the output something that can be loaded by gprof. The current situation is amazingly painful, but since it's the only game in town, we live with it.

So this past week at OSCON, I had some discussions with people around what comes after XMLHTTP for sending data to and from web browsers with low latency. Traditional polling schemes really really suck, and the alternatives are all giant hacks. Having re-written the mod_pubsub JavaScript client last year, I'm pretty familiar with what you can and can't do to and from a browser.

Or at least I thought I was.

At OSCON, I fortuitously meet Johnny Stenback, who informed me that you could indeed get multiple replies from a single request under Mozilla after I'd stated otherwise in a session. Today I started to dig a bit based on his direction and the results are interesting.

But they're not really interesting if you don't have the back story. Previously, I had thought that the only way to keep a connection open and do multiple things with it in a cross browser way was to rely on an incremental rendering hack (which is how the mod_pubsub client works). In this scenario, the client opens up an iframe and points it at a special page that doesn't close the connection. When the server has data, it synthesizes a <script> block which gets sent to the client (sometimes with some padding), which then evaluates it thanks to a "partial rendering" behavior that seems to be part of every browser since time began. The script loaded this way then calls back up to the parent page (on a special function) which then disseminates the event data to everything that had previously registered it's interest. This works pretty well, but falls into the well populated "giant, gratuitous hack" category of useful techniques for doing things in browsers.

Something better would be much appreciated. For a long time, DHTML hackers have eyed Microsoft's XMLHTTP docs with some envy as there is a stream type and an interactive mode which aren't made available to scripting, and there hasn't even been that much promised under Mozilla et. al. So back to iframe hacks we fell. But things are looking up.

It seems that it's now possible to send chunked data to the client in Mozilla on a long-lived connection, and it might very well be possible to do the same thing for IE.

Unfortunantly, unlike the iframe hack, it looks like the format on the wire will be different between the browsers (and things like Safari might still require iframes, which is yet another code branch). Whether or not any of this is a better trade-off than doing something like LivePage or the current mod_pubsub implementation is still up for debate, and only trial-and-error will really tell.

Of course, the biggest hurdle is still the scalability of servers for long-lived "zombie" connections, which things like Java servlet containers completely melt under, but Twisted Python (which mod_pubsub is now based on) indicate the way forward. I think it won't be too long before real-time monitoring and chat features turn into commonplace occurrences in the Web2.0 experience.

It'll just take another set of sexy apps to point the way forward. And a lot of elbow grease.