Re: RE: Swixml and SAX, Jelly

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
>> 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
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com