On Saturday, April 5, 2003, at 09:12 PM, John Fessenden wrote:
how exactly would one go about writing a provider that output SAX events
into the chain? I've written a content provider that uses a SAX driver I
wrote to parse some proprietary text markup, and output XML. but within
the provider I chain my driver to XML::SAX::Writer to provide a scalar for
get_strref().
is there a better way? ( more streaming) is there something I missed in the API that would allow the content provider to provide SAX events into the chain, without having the intermediate step of converting to text to pass through the scalar?
Unfortunately the SAXMachines Language processor only obtains it's data by either directly parsing data from the providers filehandle (if it supports it), or by parsing the a provided strref (I'm not sure why it doesn't try looking for a DOM as well).
The Provider interface contains no way to generate a stream of SAX events that get passed to the processor chain. In fact, the 'processor' pipeline is a bit of myth since each processor in the AxKit pipeline is run serially one after the other on the data - they aren't really chained together.
And at the end of the SAXMachines processor, the SAX events are all put into a DOM tree before sending the entire lot to the browser.
Conclusion - there's no way to 'stream' data to the browser.
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.
Regards, Chris
PGP.sig
Description: This is a digitally signed message part
