Re: RE: Swixml and SAX, Jelly

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
>>> 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
>>
> === 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