[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: Gabe Beged-Dov <begeddov@j...>
• To: Bill la Forge <b.laforge@j...>
• 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).

    2) Efficiency.

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
compatability approaches.

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
package.

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
integration easier.

> 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.

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...)

• References:
  • Re: events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
    • From: "Bill la Forge" <b.laforge@j...>

• Prev by Date: RE: Streaming XML (Was RE: XML Information Set Requirements, W3C Note 18-February-1999)
• Next by Date: Re: Well-formed vs. valid
• Previous by thread: Re: events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
• Next by thread: Re: events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
• Index(es):
  • Date
  • Thread