xml-qstat release is coming

The long promised version 1.0 is finally on its way. In the past, the major obstacle to adopting xmlqstat has been fiddling with getting the initial installation working. The addition of the CommandGenerator to the cocoon should have improved things, but instead it just added another element to go wrong. There is no obvious mechanism to add timeouts. And to top it all off, the basic command qstat -j \* isn’t even working! Either weird shell escaping or whatever, but it seems to run amok and the only viable alternative seems to be a CGI script running on a second webserver.

If we have to think about replacing the current web application anyhow (it doesn’t work with the new cocoon-2.2.x framework), Chris figured that it might make sense to try a client-side XSLT transformation as an alternative. With a standards-compliant browser such as Firefox or Opera, this seems like a good idea and might even be faster than some ancient webserver or cluster headnode would be with cocoon. Chris mentioned CGI scripting, but I immediately thought of HTTPi as an implementation platform. It is really small – 12kB before I started hacking code into it, but still under 50kB when the xmlqstat application was finished – and since it is pure-Perl, it is readily portable.

Using client-side rendering uncovered a number of minor errors in the XSLT that the mozilla engine refused to accept. It also helped identify areas in the existing sitemap.xmap logic that could be streamlined. For the transition period, and as a second development testbed, the cocoon application can also be used to deliver documents for client-side rendering.

There is still some remaining work on the installation/configuration procedure for what I’ve coined httpi-xmqstat, but I think it should be out in the next week or so.