[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
I was thinking about SAX2 and Bill Megginsons' message about the to and fro that makes open development preferable to "standards" development. I think it is very valid and so I decided to throw out my unpolished ideas :-) I have been struggling with control flow integration vis-a-vis XML parsers. I came up with some thoughts and looked back over the archives and saw that Bill La Forge had voiced similar ideas 10 days ago. Here are the relavent excerpts Bill la Forge wrote: > For SAX2, it would be great to pass objects representing SAX events instead > of method calls. The overhead might not be any greater, as the parser could > just have one of each kind of event and reuse them. > > Backward compatibility could be achieved through the use of a conversion > filter, allowing existing SAX applications to work with new parsers. > > There are two big advantages here in terms of extensibility: > 1. It would be easy to extend the interfaces for various SAX event objects, > passing additional data without creating problems for an application which > is not expecting it. > 2. Additional events could be passed which the application could ignore. Bill voices several advantages for events. If I can paraphrase, the general advantage is that once you "reify" the information about the event (that is currently the parameters of the DocumentHandler callback, you can take advantage of all the usual OO capabilities. I agree with this but I see a different advantage to making the events first class objects rather than implicit in the callback parameter list. That advantage is decoupling control flow. If someone wants to use the default control flow policy (as currently implemented) they can immediately dispatch the event using the parser's thread of control. If they want a stream based application processor that has its own thread of control, they can push the events onto an event queue. Right now, if I want to have two threads of control, one for the parser, and one for the subsystem that talks to the parser, my path of least resistance is to have the parser write a tree and then process it. I'd like to have two threads and not wait for the whole tree to be processed. Obviously this is not a big deal but it becomes trivial if SAX generates events directly. As far as the question of whether to layer a callback interface on events or events on a callback interface, the OO arguments that Bill makes argue for the former. Gabe Beged-Dov www.jfinity.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|