future change in API [Fwd: [Bug 167] New: add skipSubTree to API]

i think it is good idea and boith I and Stefan agreed to add it to 
XmlPull API in next version.

alek

-------- Original Message --------
Subject: 	[Bug 167] New: add skipSubTree to API
Date: 	Mon, 5 Jan 2004 07:15:25 -0500 (EST)
From: 	[email protected]
To: 	[email protected]



http://www.extreme.indiana.edu/bugzilla/show_bug.cgi?id=167

           Summary: add skipSubTree to API
           Product: XmlPull.org
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Design
        AssignedTo: [email protected]
        ReportedBy: [email protected]


Kevin Duffey wrote:

Fair enough, however, my request for the skipSubTree()
method in the API is not so much about performance as
it is convenience. Not having to add the extra
utilities to my small framework keeps its size down.
Of course, I just implement it now myself, so that way
I don't add the utilities, but I do see it as a
distinct advantage over other parsers in that you can
easily skip sections of xml you are not interested in.
Call me lazy, but I'd like to see that particular
method added. I was actually surprised that you hadn't
added it per our communications over a year ago
regarding it. So again I guess I ask, would it be
plausible to see it added to the API for
XmlPullParser? Or do I have to go write my own XmlPull
API and compete?  Haha, just kidding. I guess I am
hoping, but no big deal if not. I'll just keep on
using your original skipSubTree() method you pasted to
me over a year ago. Works great.

--- Aleksander Slominski <[email protected]> wrote:

>> Kevin Duffey wrote:
>> 
>
>>> >I'll definitely look into it, but why do you say it
>>> >"has to be checked for well formnedness and
>>> >namespace"? Again, I am probably wrong here, but I
>>> >would think if I have a stream of bytes from an xml
>>> >file, and I am NOT concerned about anything other
>
>> than
>
>>> >a <node></node>, even if it is invalid xml in
>
>> between,
>
>>> >as long as I jump to the </node> I don't much care
>>> >about the rest. 
>>> >
>
>> no!
>> 
>>  what about "<node><node>...</node></node>" - you do
>> not want to jump to 
>> first </node> ...
>> 
>
>>> >Of course, you bring up a point I
>>> >didn't think much about, the well formedness.
>
>> Ooops.
>
>>> >:D But, even so, perhaps for the pure essence of
>>> >speed, it would be ok to assume "most" files would
>
>> be
>
>>> >correct. But that does bring about an interesting
>>> >point, perhaps that is a sticking issue.
>>> >  
>>> >
>
>> that is tradeoff that i am not willing to make -
>> correctness of parsing 
>> and detecting errors looks more important to me than
>> some speed 
>> improvements (that are yet to be determined and
>> anything less than order 
>> of magnitude faster may not be worth it anyway ...)
>> 
>
>>> >But what about at least putting it in as part of
>
>> the
>
>>> >xml pull api so that it is there?
>>> >  
>>> >
>
>> please make a case for it including API changes and
>> detailed 
>> analysis/motivvation why this should be done (like
>> performance reasons).



------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.


-- 
The best way to predict the future is to invent it - Alan Kay


 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/qZ0LdD/yjVHAA/TtwFAA/2U_rlB/TM
---------------------------------------------------------------------~->

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/xmlpull-dev/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/