Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "Gabe Beged-Dov" <firstname.lastname@example.org>
- Date: Mon, 22 Feb 1999 15:32:24 -0500
From: Gabe Beged-Dov <email@example.com>
>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'll take that as a complement. But its David Megginson and Bill la Forge.
>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.
Overhead is an issue. Event objects really do simplify a lot of things, especially filters.
Interfaces are faster.
Worse, if the parser pulls the same tricks with Event objects as are currently done with
AttributeList (i.e. reusing the same object over and over), you must then clone the
event before adding it to the queue.
There are lots of things we could do if we had event objects, especially with control flow.
(And there's a lot of mess in MDSAX because we do not use event objects!)
But parser speed is the key feature. For now.
Though if we go with Simon's layered architecture, we might actually get a speed gain.
But there's no question that the code would be a whole lot smaller and easier to
understand. And that may be justification enough.
I would not consider this for MDSAX. But I would still argue in favor of it for SAX2.
But not without more support from the XML community.
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)