- From: Lars Marius Garshol <larsga@garshol.priv.no>
- Date: Tue, 23 Oct 2012 12:48:22 +0200
- To: "public-sdshare@w3.org" <public-sdshare@w3.org>
* Graham Moore > > But there are systems where you can ask for the changes but not get them sorted by date. One example, a web cms I've been using has a web service API where I can execute a query, but only one that matches a bunch of criteria, I cant get it to return me the sorted list. In this case the server will need to bunch up all the data before it can start streaming it. That is a problem. I guess there will be more cases like this one. > [server side developers] > > Unless there are compelling benefits client side then I'd like their job to be as easy as possible given its they who will need to work with a large number of weird and wonderful systems. There are client-side benefits, but they are not huge. I'm guessing this is likely to be a persistent annoyance in practical use, that is, something that people accept with a sigh. One way to solve it would be to allow the server to assert in the fragment feed that it is sorted. However, for that we will need either a new extension element (which I'd rather not have) *or* a new link type to an RDF description of the collection. An RDF description might have all sorts of uses, and I think if SDShare ever becomes a success we'll be forced to do it (which is fine). It struck me that we *could* solve this outside the spec. There's no reason why I can't add to the SDShare client support for saying in configuration that "we know this fragment feed is sorted". The client can then (a) verify it and crash if it ever finds a counter-example and (b) update time stamps even in the case of failure (for these feeds). Thinking about it I like the configuration solution best. --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/
Received on Tuesday, 23 October 2012 10:48:56 UTC