display | more...
So I recently whapped the edev list with a link to my recent XSL work, via a proxy widget at W3C that marries XSL transformations to XML files that don't specifically ask for them. My stylesheet, the output of which is available at <http://www.w3.org/2000/06/webdata/xslt? xslfile=http://www.gibberish.com/hacks/e2/catboxstyle.xsl&xmlfile=http://www.everything2.com/index.pl? node_id=1259846&transform=Submit>, takes the Universal Message XML Ticker and renders it into HTML on the client side. (Or, well, at the moment it renders it on the server side, but at least it's not our server. Whether anything but the W3C's widget can actually handle the advanced XPath fu in this stylesheet remains to be seen.)

What's the point of that, you ask? Well, I'm no longer totally sure, but I can tell you what the point was when I started.

I've heard much talk about the strain on the database and server when people sit on an expensive page and chat for extended periods. And really, when you consider that the user in question just wants to reload the chatterbox, all pages are expensive. There's no reason, technical or otherwise, to send the whole page over again just to refresh chat. The challenge, then, was to find a way to refresh one without the other.

My idea was to use the existing chatterbox XML ticker to render the chatterbox on the client side, in the browsers that support client-side XSL. The resulting chatterbox simulacrum would then be targeted to an <iframe> tag, which sits in the browser like an image but can hold a separate HTML document like a frame. The chat form could then simply be targeted to a new ACTION attribute that only returned XML, and targeted the <iframe>. Users on non-XML-savvy browsers would simply get the old chatterbox. I even have some JavaScript that can dynamically resize an <iframe> so it scales to its content - no ugly scrollbars!

But - and the worst thing is that it took me until I got the XSL working to realize this - XML is optional to this whole scenario. It wouldn't cost the server more to create a tiny static-HTML page of the current catbox than it does to create a similar XML page. Such an HTML page could then get stuck into an <iframe>, or even (God forbid) an <ilayer>, and get us a more stylish catbox even in browsers that don't deal with XML. If we're willing to put up with scrollbars, we could even lose the dependence on JavaScript.

Here's the thing, though: is there a point? Would the elimination of the bandwidth inflation caused by chat reloading outweigh the fact that everyone who had the chatterbox turned on (and had a requisite browser) would be making TWO HTTP requests, rather than one, every time they loaded a page and weren't chatting? The savings to the database and computation time might tip the balance slightly in favor of an iframed chatterbox, but not by a whole lot... especially given all the people who just sit there looking at the catbox at any given time, and don't use it.

So, in the end, I may have produced a very cool useless hack and nothing more. It'll be worth it, though, if I can open the possibility of in-browser, client-side rendering up for someone who's working on a problem that really does need it. I would certainly be willing to lend my expertise to any such project.

Log in or register to write something here or to contact authors.