Re: v1.89 3.10a - Iterative Query

Seaborne, Andy wrote:

>Isn't this design objective a cursor mechanism as it says "fetching in
>chunks" and cursors are out of scope by 2.3 of the charter?
>  
>
I think that "fetching in chunks" does not imply a server side cursor 
requirement that maintains state on the server.

In my experience with OASIS ebXML Registry (ISO 15000 part 3 and 4) this 
can be supported without any requirement for maintaining state on the 
server via a cursor mechanism. All that is needed is for the query 
syntax to allow specifying a startIndex and maxResults parameters. The 
maxResults parameter is covered by the original result limits (3.10). 
The startIndex parameter allows specify the begining of the next chunk 
of data. The response returned includes startIndex for the chunk of data 
returned and totalResultCount to indicate how many results actually matched.

See section 8.1.4 in:

http://www.oasis-open.org/committees/regrep/documents/2.5/specs/ebrs-2.5.pdf

>The result limits (3.10) is a more useful requirement in that it allows a
>client to limit the results size in case of asking for too much.  This is
>different from fetching in chunks.
>  
>
I see "fetching in chunks" as extending the capabilities of result 
limits (3.10) by providing an additional control parameter to the client.


>I think we should rely on the mechanisms that the underlying protocol can
>supply even though these can be difficult to control.  e.g. TCP flow
>control.  Writing server code that tracks the state of partial client
>request can be every limiting; mis-behaving clients can intentional or
>unintentionally attack the server.
>  
>
I totally agree. However, I think that server side tracking of partial 
client request is not needed to support the suggested extension to 3.10 
to support "fetching in chunks".

-- 
Regards,
Farrukh

Received on Tuesday, 25 May 2004 10:23:03 UTC