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, Forum@carlsbadcubes.com 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.
--- Forum@carlsbadcubes.com 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, Forum@carlsbadcubes.com
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.
--- Forum@carlsbadcubes.com 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
considered
pull. I have also
used Piccolo and NANO where size and speed ready
mattered.
Since I do work on embedded systems as well, I
understand the
requirement for size and speed well and I have
done
optimizations that
made code maintainability more difficult - but I
always had a good
reason.
At this point, I'm not so sure that we should
sacrifice readability and
understandability of the Swixml code to reduce
the
size and improve the
speed.
The jdom.jar is about 128 kb, which is huge
considering the size of the
swixml.jar. On the other hand most project using
Swixml deploy over an
Intranet - so deployment size really doesn't
matter
all that much.
Unfortunately, only a few Swixml users tell us
how
they use it ...
Everyone would certainly benefit form
improvements
in processing speed
- but usually Swixml descriptors are not 13MB -
well
at least not those
that I have written - and speed improvement would
be
less impressive
than those mentioned below.
Pull parsing really seems to be the way to go but
there are other - at
this point maybe more important - things that
need
to be done.
Maybe I'm misjudging the download size /
execution
speed issue.
Is there anyone who considered using Swixml but
didn't because of the
download size or parsing speed?
Wolf Paulus
C a r l s b a d C u b e s
mailto:[EMAIL PROTECTED]
On Jan 2, 2004, at 9:03 PM,
Forum@carlsbadcubes.com
wrote:
I agree, an XML pull parser would be perfect for
this application,
however
either SAX or XML pull parsing would be a great
improvement.
Don
On Fri, 2 Jan 2004 Forum@carlsbadcubes.com
wrote:
Frankly, I think you really should look at
using
xml
pull parsing. For the type of xml parsing you
do,
xml
pull would be super easy to implement, is quite
a
bit
faster than SAX and is a mere 9K library that
you
can
legally integrate directly into your swixml.jar
file.
I use it for my plugin engine and it is amazing
how
easy and fast it is. The only sax parser close
in
speed is picollo and I am not even sure where
it
stands now. xml pull is super easy:
InputStream is = new
FileInputStream("somefile.xml");
XmlPullParser parser = new MXParser();
parser.setInput(is);
parser.next(); // move to first node
int event;
while ((event = parser.nextTag()) !=
XmlPullParser.END_TAG)
{
if
("menu".equalsIgnoreCase(parser.getName()))
{
// do something
}
else if
("button".equalsIgnoreCase(parser.getName()))
{
// do something
}
else ...
{
}
else
{
skipSubTree();
}
}
=== message truncated ===
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
