It could be fun to try and rebuild AxKit to instead do proper pipelines. I would envisage that the entire pipeline would actually become a series of SAX::Machines (or similar). A language processor like XSLT would be required to collect all the SAX events and construct a DOM before processing - and then regenerate SAX events from the result to send to the next processor. Of course optimizations would be added to just pass along the full DOM instead of serializing to SAX events if the next processor would just consolidate them again (and the same for providers).
Then there would need to be some tricky handling at the end of the pipeline to store the SAX events until the headers can be sent (eg. the final content type, etc, is determined), after which the data would just be sent to the user as it becomes available.
Of course caching would become a little more tricky!
But any of these ideas would _seriously_ change the way AxKit works and would most certainly be totally non-backwards compatible.
I already built something like this that I named "axkitb2b". It does all of what you suggest, and includes caching via XML::Filter::Cache.
I stopped due to laziness and lack of a real need for it, and because I didn't want to do the hard bit (a configuration system - I wanted to do a GUI for it).
Matt.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
