events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))

[Gabe Beged-Dov]

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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)