| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
So you are agreeing that sax/xmlpull is better than
jdom?
Let's not toss JDOM out on it's heels. JDOM kicks butt
in simplyfing xml parsing, but let's take the pros
with the cons. I agree with Brian, as I have said,
JDOM not only parses the full doc before you can
access any of it, it also creates the object model of
the doc in memory, and thus larger xml files equate to
a lot more client side memory usage. Hopefully after
the xml is used, the UI rendering is done and the doc
is freed so it doesn't sit in memory?
Without trying to destroy the credibility of swixml, I
am hoping that my last sentence there is wrong, and
that after the UI is rendered the xml doc, jdom object
model, etc is no longer left in memory? If this is the
case, then why even bother reading the entire doc in
at once, why not just render the UI as nodes are
found? sax/xmlpull work well at this. Of course you
probably have to parse a section of nodes before you
might have a complete picture, unless you use a single
node to represent a complete swing object.
Anyway, I still stand firm on my argument that xmlpull
would be at least a bit faster if not a lot faster and
would reduce the runtime client side resources (namely
memory) needed, as well as provide a much smaller API
(which Brian does a good job of making clear is the
least of the problems).
--- [email protected] wrote:
> Wow, I haven't seen this much debate for a while
> now.
>
> I actually think JDOM is good and bad. JDOM builds
> an in-memory
> document tree of , Document class.
> If the application uses small snippets of XML, e.g.,
> for dialog boxes,
> panels, etc, then the parse will go
> very quickly and use very little client resident
> RAM.
>
> But if the application wants to use one XML file for
> an entire
> application, then the memory needed can be quite
> substantial.
> Everyone in this conversation seems to worry about
> the jar download
> size, 20k here, 20k there. Well, that's all fine
> and dandy.
>
> But if you need 64MB of client ram just to parse the
> doc, then the only
> point of keeping your jar files small is for Applet
> code that is used
> infrequently and
> with very few repeat users.
>
> If you are using applets, once the browser has
> cached the jar files,
> the user doesn't need to re-download them until
> their cache gets
> cleared, or
> a newer version of the jar file exists.
>
> So we are really only talking about saving a few
> seconds, once or twice.
>
> Now, if you download 3M of Jar files, once, but can
> process your
> document faster and with less client resident RAM,
> than that
> provides a better architecture overall (of course,
> unless your that
> applet developer with few repeat users).
>
> Just me two cents.
>
> Brian
>
> On Saturday, January 3, 2004, at 04:53 PM,
> [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
>
=== message truncated ===> BEGIN:VCARD
> VERSION:2.1
> N:Michael;Brian;P
> FN:Brian P Michael
> ORG:GoldParrot Corporation
> TITLE:President
> TEL;WORK;VOICE:630-897-8364 x17
> TEL;WORK;FAX:630-897-8364 x21
> ADR;WORK:;;1326 Eastwood Dr;Aurora;IL;60506;USA
> LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1326 Eastwood
> Dr=0D=0AAurora, IL 60506=0D=0AUSA
> EMAIL;PREF;INTERNET:[email protected]
> REV:20020311T030256Z
> END:VCARD
> >
> > _______________________________________________
> Forum mailing list
> [email protected]
>
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003