Re: Sorting by app:edited & Concurrency

["A. Pagaltzis" <pagaltzis@xxxxxx>]

* Brian Smith <brian@xxxxxxxxxxxxxx> [2007-11-14 02:55]:
> (a) Is the server doing anything wrong? Is an AtomPub server
> required to ensure that entry B does not appear in the feed
> until entry A appears in the feed?

No, there are no requirements on the ordering of request
processing. They would make scenarios like loadbalancing
a lot more costly, f.ex.

> (b) Assuming that the server correctly implements the
> app:edited and page order requirements from RFC 5023, how
> can a client catch up with a collection feed, using the
> minimum number of requests?

Just page backwards until you see an entry that you already
have in your cache, whose app:edited value on the server
matches its value in your cache. (This is in fact the point
of sorting the collection feed by app:edited -- efficient
synch.)

> (c) In step 4, is the server required to include entry B in the
> feed? Does the collection feed need to be updated immediately,
> or can it be updated asynchronously? For example, would it be
> legal for a server to update the feeds once every five minutes,
> regardless of how many POST, PUT, and DELETE requests are
> received in the interim?

Asynch updates are fine, I think. I don't think we have any
language in the spec that allows a client to expect immediate
collection feed updates.

Note that clients that have POSTed or PUT an entry should synch
by GETting the `edit` link from the entry in the response body.
*That* should in fact be updated immediately. So clients can
always get an updated version of the entry they’re currently
interested in.

Don’t forget that clients normally have no indication of when
changes on the server might have happened. It’s just you are
thinking of a scenario in which it seems reasonable that the
client can know that the collection feed has changed. But the
collection feed might also change at any other time! The client
can never know – it can only ever know the server-side state of
the collection *right now* by polling *right now*.

So the only practical consequence of updating collection feeds
asynchronously is that clients cannot keep *realtime* synch with
the *entire* collection on the server by *continuous* polling.

Big whoop. :-)

> (d) Which (if any) AtomPub server implementations are sorting
> by atom:updated instead of app:edited, and/or omitting
> app:edited entirely? And, how are clients coping with these
> servers?

In that case the client doesn’t have any other option than to
page through the entire feed every time. There’s no way around
it. That’s why collection feeds SHOULD be ordered by app:edited.

Note that servers are free to offer any number of feeds for any
one collection, eg. by putting atom:link elements inside an
app:collection. Only the main collection feed (ie. the one linked
from app:collection/@href) SHOULD be sorted by app:edited. Others
could be sorted in any way whatsoever.

So if servers want to offer feeds sorted otherwise, they should
offer them *in addition* to the app:edited-sorted collection feed.
Clients that understand the extra links can then make use of
them, and clients that don't, will still work smoothly.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>