- From: Dirk-Willem van Gulik <dirkx@webweaving.org>
- Date: Mon, 28 Jun 2004 09:39:37 -0700 (PDT)
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "Eric Prud'hommeaux" <eric@w3.org>, public-rdf-dawg@w3.org
On Mon, 28 Jun 2004, Seaborne, Andy wrote: > 1/ The streamability requirement as the result is a graph. While it is > possible to insist that the serialized graph come back in a useful order, > this does not feel like a useful way to go. It is effectively a new > serialization that is compatible with the unrestricted one. Given that relatively simple/primitive protocols like, say, one build around HTTP GET based on a single TCP channel almost always lack an async throttle or stop; I'd suggest that once an aswer has started comming it is essentially unstoppable wihtout 'breaking the connection'. So you have to wait until it is all there. And if you reconnect all you can use are simple things like Byte ranges or other record based deliniators. So having an order within chunks on that level of granulairyt (i.e. in the req/response) is of very little use; unless you use an async/multiplex protocol, or one iwth a cmd channel, like beep or ftp, order within the serialization is not going to matter. So I'd rather not bother about useful other in those granules - but ensure that you can get some control over replies on a higher lever; i.e. hints/allow more refined queries and/or warnings/limits (say GET-if-modified, GET-if-smaller-than) or whatever. It may matter on the receiving end - i.e. for efficient memory use - but in actual practice that is a) highly system dependent and b) often driven to some level of optimization by the developers as a natural thing. Dw
Received on Monday, 28 June 2004 12:49:45 UTC