Re: RE: Swixml and SAX, Jelly

You are correct in that JDOM allows direct
manipulation of the full document, at the expense of
eating up about 8x more memory than the document size.
If there is only ever one tiny xml file, no big deal,
I agree and said this before that JDOM is probably
pretty good for small files. In my UI framework I was
looking at the potential of 100's of small files all
being used to build parts of the UI. This wouldn't be
feasible then using something that eats up so much
memory.

Lest not forget that JDOM takes longer to parse the
file into an object model than parsing the document
using xmlpull by over 7x. In other words,  you could
parse the doc 7x by the time JDOM makes an object out
of it for you, and each time you need to access a
specific node, that isn't free either. JDOM has to
traverse it's object model to find your node(s) you
need, each time taking some processing power as well.
I am sure it uses something like a Map with key/value
pairs to jump faster to specific nodes, or linked
lists or something, but it still requires a little
time each time you need to jump to a node.

--- [email protected] wrote:
> ok,  so it's one jar instead of 2...and I wasn't
> implying that it was a 
> large jar I was stating that if you add ANY
> additional jars you are 
> increasing the download size from it's minimum
> potential...which is NO 
> jars.  20k > 0k   Plus... kxml2 requires the XMLpull
> jar to compile 
> which means that even if it isn't a separate jar the
> code has to be in 
> there so it's roughly equivalent.
> 
> You're correct about it not being built on SAX, my
> mistake, but 
> regardless the point still remains that if you want
> the fastest 
> rendering with the smallest download then adding ANY
> jar is 
> counterproductive.
> 
> I'm not saying XMLPull isn't simple. I actually like
> XMLPull. But, JDOM 
> isn't a linear processor. you're not limited to what
> comes next. You 
> can traverse the tree however you want. Which leaves
> open a lot of 
> possibilities for future expansion and for the use
> of plug-ins, when we 
> finally get them in there. Imagine if your plug-in
> could get a copy of 
> the current jdom document. you could make all kinds
> of decisions based 
> on where you are in the structure of Swing objects.
> But, if you're 
> working with an xmlpull object then there really
> isn't a good way to 
> see what's come before you, unless I am remembering
> this incorrectly 
> too, and then there's the issue of what happens to
> the pointer in the 
> XMLPull object when the plug in has moved it
> forwards?
> 
> While Wolf hasn't officially said there will be
> plug-in support in a 
> future version the conversations we've had on this
> list make it look 
> like that is a very real possibility that would
> fulfill the needs / 
> desires that have been expressed by the community of
> users.
> 
> -Kate
> 
> 
> On Jan 3, 2004, at 3:45 PM, [email protected]
> wrote:
> 
> > Kate,
> >
> > I hate to be the bearer of bad news, but you have
> your
> > information on xmlpull very wrong. I use a single
> > kxml2.jar file that provides the xml pull api
> factory
> > class and an implementation that is like 9K in
> size.
> > Actually it's a little bigger, like 20K now, since
> > they added a serializer to write xml out and a few
> > extra methods.
> >
> > Even so, the "extra" class you are talking about
> is
> > like 20K also, so what, 35K or so is huge compared
> to
> > the 1MB or so for xerces and even 150+K for most
> sax
> > parsers? I don't see where you add those sizes up
> and
> > they are larger?
> >
> > Also, who told you xmlpull is implemented over a
> sax
> > parser? Wha? I don't think so. I gave a very
> simple
> > snippet of exactly what it takes to use it. I used
> > JDOM for several months, then switched to SAX2 for
> a
> > couple of months, then went to xmlpull and haven't
> > looked back. I am actually implementing my own XML
> > pull parser for an even "simpler" use of it, for
> > handling config files which don't need anything
> other
> > than the xml nodes, no white space, no name
> spacing,
> > etc. I will use the API, but provide my own
> > simpler/faster implementation for specific uses of
> my
> > plugin engine and those wanting a very fast easy
> to
> > use config file read/write parser.
> >
> > I think you need to check your facts a bit before
> you
> > post on something you clearly don't know a lot
> about.
> >
> >
> > --- [email protected] wrote:
> >> I've used XMLPull and I've used SAX and I've used
> >> JDOM
> >> yes XMLPull is easier to read than SAX,  but the
> >> last time I checked
> >> you needed 2 Jars to get XML pull working.. one
> the
> >> core classes and
> >> one for the implementors of those core classes.
> >>
> >> so, you've lost your download size advantage.
> >>
> >> XMLPull is a wrapper around SAX, so now you've
> gone
> >> and added
> >> processing overhead.
> >>
> >> so, if your goal is a faster smaller app it makes
> no
> >> sense to use
> >> XMLPull. SAX is annoying yes but if you're going
> to
> >> do the work to make
> >> the app faster then it really doesn't make any
> sense
> >> to add a wrapper
> >> around the fastest possibility.  (This is
> assuming
> >> SAX really is the
> >> fastest option)
> >>
> >> now, if your goes is easy of use and
> >> maintainability, then I have to
> >> agree with Wolf that JDOM is the way to go.
> >>
> >> I should note that I have nothing against
> XMLPull,
> >> it just isn't the
> >> right choice if you're truly after speed and
> size.
> >>
> >> -Kate
> >>
> >> On Jan 3, 2004, at 2:34 AM,
> [email protected]
> >> wrote:
> >>
> >>> I'd say for what it is used for swixml is
> probably
> >>> just fine with jdom. I personally prefer pull
> >> parser
> >>> for size and speed and memory resources. But
> then
> >>> again I am a performance nut who will sacrafice
> >> some
> >>> things for speed.
> >>>
> >>> That said, I don't see how the xml pull parsing
> is
> >>> harder to read than jdom? I find it easier. It
> is
> >>> simple string comparisons. Yes, a bunch of if
> >>> ("..".equals())) else if () else if() isn't
> always
> >>> pretty, but it is fairly easy to read and easy
> at
> >> a
> >>> glance to know what specific node(s) you are
> >> working
> >>> with. So I would have to disagree that pull
> parser
> >> is
> >>> harder to read in code, and at the same time it
> is
> >>> much smaller, quite a bit faster and uses a lot
> >> less
> >>> memory resource at runtime. With all great
> things
> >>> comes sacrifice, and that would mean no
> dtd/schema
> >>> validator without an add-on to the pull parser.
> >>>
> >>>
> >>> --- [email protected] wrote:
> >>>> I'm writing Java apps (server side,
> client-side,
> >>>> JSPs etc) processing
> >>>> XML for a little mote than 4 years now.
> >>>> JDOM and Jaxen (XPATH) have been proven to be
> >> useful
> >>>> and effective!
> >>>>
> >>>> Yes, I have used SAX and "pure" DOM and
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003