Re: Streamability II

>>> <snip/>
>
> I don't think this is too hard a problem to crack. As Andy mentions, a 
> ResultSet implementation is backed by a model that makes calls to the 
> server when results, so for example, results could be paged, and when 
> a page of results is iterated over, a new page is fetched. In fact 
> we've implemented just such a scheme in TKS/Kowari. There is no 
> additional overhead on the part of the client developer.
>
> I see the concept of streaming as being vitally important. When you 
> deal with large results, using memory to cache them, simply doesn't 
> scale.
>
> I'll see if I can rustle up some more implementation details.

As promised, for those concerned about implementability, here is an 
outline from one of our engineers of our approach to streaming results 
across the wire:

"When a remote query is performed, the ResultSet is wrapped in a paging 
class that can return a page of results at a time. On the client side 
is a class that meets the ResultSet interface and calls across the 
network to this paging class. When this client-side ResultSet class is 
returned from a query it contains its first page. Iterating over the 
client-side ResultSet just iterates over the results in the internal 
page. Once a page is finished, the next page is automatically requested 
from the paging class on the server and iterating can continue."

I have some further information page sizes and network overhead if 
anyone wants to dig deeper.

Cheers,
Tom
-- 
Tom Adams           | Tucana Technologies, Inc.
Support Engineer    |   Office: +1 703 871 5313
tom@tucanatech.com  |     Cell: +1 571 594 0847
-----------------------------------------------

Received on Monday, 21 June 2004 13:30:50 UTC