| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
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
> 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,
> [email protected]
> >> 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 [email protected]
> 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