[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX and Pull options: was: Penance for misspent attributes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Dennis Sosnoski [mailto:dms@s...] > > There are a couple of points I'll comment on in this. The > first is that > SAX doesn't really function as an event based architecture > component because it's relying on the application to give it > control in > the first > place - the application thread is what executes all the > parsing, as well > as the call-backs to the handler. This is implicit in the SAX > specification since it does not address any synchronization > issues that > would needed if different threads could be used. That's not necessarily the case. SAXHandlers can be deployed into a system and then dispatched to; who invokes the parser is moot. > The second is that the servlet architecture that forms the > basis of most > application servers is not really extensible to non-blocking IO. > The servlet model ties up a thread until all processing of a > request is completed, so you may as well have the thread just > wait for > input if needed. Having a synchronous application layer is not a good reason to stay with a synchronous server layer. Thread per request is part and parcel of the Servlets specification (and thus JSP also). One workaround is to fire events straight through to a proxy which handles associated io buffering and servlet invocation (you can think of the proxy as marking a process boundary). One would hope to see a standard that invalidated thread per request programming for machine to machine work particularly for intermediary data processing and rewriting. XML Pipeline is an option, as is ... SAX. > >when I could have had a runtime binding based on the types of > >the visitor and visitee and internal iteration (presumably the > >parser is best placed to know the token type) via double > >dispatch. > > > I think this kind of misses the point of using a pull parser. Then perhaps I'm not seeing the sweet spot for a pull parser API; I think it's somewhere between SAX and DOM, but I'm wondering how difficult is it really to manage state cleanly by building on top of a well known API, versus learning a new API that may have maintenance issues down the line. All said, I don't see the simplicity win in XPP. > Using some simple utility methods I can parse the data content of > the document very easily with direct inline code, rather than > having to use > a state machine. I think this is a much more natural style of > programming for most developers - a top-down structure in the > code that > reflects the structure of the document. I do think it's natural; procedural programming often is. It's the maintenance and life of the code that bothers me. A standard that legitimizes switch blocks over polymorphism where polymorphism is available is open to question. Once those typecodes are standardized the only way for me to refactor them and get the code under control is to add /another/ layer, that encapsulates typecodes behind objects or as a first cut, typesafe enumerations. As I said, the typecodes are an implementation detail spilling out into the API; upgrading them to at least to tokens will save people some hassle later on. > I could wrap a pull parser in handlers to give the same > effect as a SAX > parser interface - in fact, Alek Slominski has actually > implemented a prototype SAX2 push layer on top of a pull parser > (http://www.extreme.indiana.edu/xgws/xsoap/xpp/). Trying to > turn a push > interface into a pull interface is much more difficult, basically > requiring a separate thread and associated threading overhead. Well building async (SAX) atop sync (XMLPULL) is a bit odd. The other way around can be dealt by inserting a queuing layer, this way async and sync layers don't communicate directly, concerns remain separated and concurrent. Bill de hÓra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPOpTLeaWiFwg2CH4EQLTcgCfTWgp+ft6MzRGCVOhSY069a/4vlMAn0uR xgtDm0ZiolYOKHfOkkMQEslx =PJQi -----END PGP SIGNATURE-----
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|