| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
Kate,
I'll agree for the most part. If the xml files are
small, it's not worth the effort to change things now.
I don't understand the dilema with plugins though.
What does that have to do with anything? A plugin is
going to be a filter to the processing of xml? If not,
then the document is always parsed before/after a
plugin can access it anyway, so I dont see why this is
a big issue for you. Then again, I don't know much
about what plugin engine you'll use, what plugins will
do, etc. What is the purpose of plugins in swixml? I
thought it can already be used to add custom widgets?
I will still strongly argue that xmlpull is faster,
smaller and easier to read than sax, and I will
strongly argue that it is easier to read than JDOM. I
don't see how:
if ("nodeName".equals(parser.getName()))
{
}
is hard to read? It's about as beginner as it comes.
You compare a node name string to the name of the node
string the parser is currently at. JDOM you have to
work with Document, elements or something like that
(sorry, its been two years, not sure where it stands
now). So, I will say that if JDOM has gotten a lot
easier in the past two years, I retract on the easier
part. But, like I said, xmlpull is faster than sax.
You don't have to parse the entire document, you parse
what you want, tha alone means you could parse one
node and toss out the rest of the doc. Sax is event
based and if I recall right is similar in that if you
want a start node event, you need to figure out which
node it is using string comparisons as well, similar
to xmlpull, but quite a bit uglier in code.
I suppose I can end this saying that you probably wont
change your mind, and it doesn't appear I am, so let
bygones be bygones. You believe sax is faster/smaller
than xmlpull, and that jdom is easier to read. I
disagree, life goes on.
--- [email protected] wrote:
> I don't think anyone's arguing that JDOM is faster,
> or that it doesn't
> use more memory.
>
> This discussion started with someone stating that
> they wished there
> wasn't an extra jar to download and that the
> processing was faster.
>
> along the way the following points have been brought
> up
> 1) jdom is easier to read and maintain
> 2) something that provides a full document model to
> future plug-ins,
> like jdom would, has some definite advantages, and
> would probably be
> necessary.
> 3) jdom is not the fasters or smallest solution
> 4) XMlPull requires an addition jar download just
> like jdom (which
> negates it for the whole smaller faster argument)
> 5) SAX is definitely the smallest (no additional
> download), and
> probably the fastest, solution.
> 6) SAX or XMLPull would have a number of negative
> issues when passing
> it off to plug-ins
>
> now, I'd like to add that even if JDOM is eating up
> 7 or 8x the memory
> this isn't an issue. Has ANYONE here written a
> swixml doc that was more
> than a few k? bigger than a meg? I would suggest
> that arguing about the
> memory requirements are relatively pointless because
> no-one is going to
> be making a SWIXML doc > 500k anytime soon. If you
> do you should
> probably rethink your gui because that's a lot of
> widgets. Once the
> doc is processed SWIXML doesn't need to hold on to
> it, so it can be
> garbage collected. so even if you have hundreds of
> files they're not
> going to all be sitting around. If Swixml isn't
> doing this currently it
> probably should.
>
> with this in mind I think we can say that we have
> two viable options
> for the future
> 1) leave things as they are until something smaller
> and faster than
> jdom comes along that can still offer the whole
> document to plug-ins
> 2) switch to sax and limit the options for plug-ins.
>
>
> Remember that no-ones is arguing that the system
> couldn't be made
> faster and smaller. We all know that. The issue is
> whether or not it's
> really WORTH the effort, the limits to plug-ins, and
> the extra
> maintainability issues to make it smaller and
> faster.
>
> -Kate
>
>
> On Jan 3, 2004, at 6:02 PM, [email protected]
> wrote:
>
> > 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003