In the background I've been quietly working away on AxKit B2B. I've mentioned this before in my journal, and mostly it's an experimental project to try out some new SAX techniques. To that end, writing AxKit B2B has been mostly an exercise in writing SAX drivers, filters and handlers. I've got XML::Filter::XSLT done, and now I'm working on XML::Filter::XSP, XML::Handler::AxPoint, XML::Filter::Cache, and a few other bits and pieces.
Beyond all that, the code is just a glue between:
1. A POE HTTPD. This can at some point be converted to mod_perl, but making it POE makes it much lighter to develop and test on my laptop.
2. A config file reader. This is probably the most complex bit of the program! It needs to cope with runtime changes and still manage to be lightweight enough to not bog down the system.
3. The glue, which maps HTTP requests to SAX Machines (using, of course, barrie's excellent XML::SAX::Machines).
The mapping is what I have to design next. Cocoon seems to only allow mappings based on URI/filename, but I'd like to have the current AxKit flexibility to use either the DocType public ID, or the system ID, or the first element's name. It would also be cool to continue to allow <?xml-stylesheet?> processing instructions to work, but probably not a priority.
Unfortunately some of this requires re-implementing a lot of what would be a HTTP server. But I think it's worth it - having mod_perl running on my laptop with only 64M of ram, plus doing presentations in X, really cripples it.
