Lists Home |
Date Index |
- From: Gabe Beged-Dov <firstname.lastname@example.org>
- To: Bill la Forge <email@example.com>
- Date: Thu, 25 Feb 1999 20:50:05 -0800
Bill la Forge wrote:
> >Event-based programming existed before people started encapsulating
> >events in structures or objects. I'd define SAX as an event-based API
> >that reports events using callbacks.
> But why are we not taking advantage of having the events as objects?
> I've tried to second guess why this is so, but I think the arguments in
> favor of object-based events is stronger: the added overhead is balanced
> by greater simplicity and subsequently less overhead in other areas; the
> added flexability adding additional utility to all conformant code.
I'll play devil's advocate in order to keep this thread going :-). The two reasons
I can see for prefering the current API are:
1) Good old installed base argument (doubly so with the SUN XML direction).
The first is a classic trade-off of increased flexibility and maintainability in the
future vs. transition costs in the present. It can be handled with the usual backwards
The second can be dealt with by deciding if you want to provide an event object vs an
event interface. The event object requires SAX to do a deep copy of the event
information in order to decouple it from the parser. If you just want the benefits
that Bill is advocating, you can go with the event interface and allow the same tricks
that are currently used. You could then support the deep copy in the helpers
The next step would be to use theEvent interface at the "raw" API level in order to
obtain the extensibility without sacrificing efficiency and support an event queuing
layer above it where streaming application integration is available.
Flexible control flow integration is very hard when everybody thinks they're in
charge. An event interface (with an event object layer above it) makes this
> The same will be true of SAX2, if events are objects. It will dramatically increase
> the utility of all the conformant code!
I agree. If you document that SAX owns the event and provide convenience routines to
do a deep copy, it seems like you can have the
best of both worlds.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)