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?
>, 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.
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.