Lists Home |
Date Index |
- From: "Bill la Forge" <firstname.lastname@example.org>
- To: "David Megginson" <email@example.com>, "XML List" <firstname.lastname@example.org>
- Date: Fri, 26 Feb 1999 08:51:29 -0500
From: David Megginson <email@example.com>
>In two or three years, I fully expect to see people (unknowingly)
>using SAX on the next-generation of palmtops with wireless Internet
>access, choosing a new sweater to buy from Eddie Bauer while they're
>riding the bus back to campus -- at least, I hope to see that, as long
>as we're smart enough not to kill off SAX's original advantages in
It is hard to make a definitive case when there are so many right answers.
And with monolithic parsers, you are right. But with event objects, we can
go with a layered approach and achieve a better integration between
applications and parsers. And in palmtops, you know those applications
will need that close integration just to keep the footprint small.
So for the very applications you are concerned with, the larger jar file needed
by an event-object approach could be offset by that tighter integration.
I hate bloat, but there's more than one way it creeps into the code. MDSAX would
be smaller with event objects. Total application bloat is significantly reduced when
you can increase the utility of the components--you have just cut out a lot of
duplication and work-arounds!
And with the continued pace of hardware, the real issue isn't the size of a resident
jar file, but the size of the jar files that need to be downloaded. If we can increase
the utility of our components, then we will likely have those components resident
on the palmtop. And the applications being downloaded will be ever so much
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)