To sort or not to sort

The current draft[1] says that the order of fragments in the fragment feed is undefined.

This is good for server implementors, as it means they can pump the fragments out in any order they choose. Less work for them.

However, it has a cost for clients. It means that if the fragment feed is large, and something goes wrong during processing of fragment number 60,000 the client cannot update its local "last fragment seen" time, because the feed may contain other fragments dated before that time which it hasn't read yet. So if it sends a new request with ?since updated it may lose fragments. That means it has to go through all the 60,000 fragments again, which takes time.

It's also clumsy when debugging. In practical use you often make a change in the data source and want to see if it shows up in the feed as it should. Now you have to search through the entire fragment feed to find your change. If the feed were ordered by time you'd know that your last change should be at the end of the feed.

So what is the right choice here? Should we require fragments to be ordered by time ascending (oldest first), or leave it undefined?



(To those of you who are new to SDshare: if you feel you need some sort of introduction to the spec before you can discuss this sort of issue, please let us know, and we'll see what we can do.)


[1] http://www.sdshare.org/spec/sdshare-current.html

-- 
Lars Marius Garshol  |  Consultant
Bouvet ASA Sandakerveien 24C D11 Postboks 4430 Nydalen NO-0403 Oslo
Phone: +47 23 40 60 00 | Fax: +47 23 40 60 01 | Mobile: +47 98 21 55 50
http://www.bouvet.no

Received on Friday, 12 October 2012 10:13:31 UTC