[Exist-open] Re: Re: Re: XMLDB API

[Kevin O'N. <ke...@ro...>]

>> Why is it obviously more performant?
> 
> The driver cannot do less work than simply piping results through to the
> user at the very moment when they arive. No memory required (in the case
> of SAX events). No object generation. No administrative work. It's that
> simple. (Always think of the trivial processing task to write the result
> set into a servlets output stream. In this case the attached SAX handler
> might be a trivial XML Writer or something similar.)

An iterator gives the driver developer control over the document
instantiation point.  

>> How does the push model work in a stateless environment like http?
>> Couldn't the push be laid over and iterator? How do I implement a skip
>> type process, eg I only want results 6 though 10?
> 
> What is the problem with HTTP? The HTTP response contains a single result
> set, no matter how large.

Ahh ... but this is what you normally want to avoid. I recently had the
displesure of working with a system that returned a set of files this
way. It was trivial run the client out of memory by simply calling a large
enough result set. Yes there are work arounds (otherwise we would not have
been able to deliver the system).

Given what you have said I believe that your callback interace would be
pretty easy to lay ontop of the iterator interface. 

Having said that. I think that the ability to handle a resultset via an
event stream is a good idea. Thanks for taking the time to discuss this
with me. Providing both an iterator type result and a event type
result would allow for both styles of operation. The event based
processing may be highly effecient in cases where the driver has in VM
access to the result nodes.

-k.