Sorting by app:edited & Concurrency

["Brian Smith" <brian@xxxxxxxxxxxxxx>]



Consider this sequence of events, between a single client and a single server. The server pages entries so that there is only one entry per feed page.

 

1. Client POSTs entry A. Server chooses 2007-11-12T12:34Z as entry A's app:edited property.

 

2. Client POSTs entry B. Server chooses 2007-11-12T12:34.1Z (.1 seconds later) for entry B's app:edited property.

 

3. Server finishes adding entry B to the collection, and returns the appropriate response to the client's POST of entry B.

 

4. Client GETs the collection feed. Since only entry B has been completely processed, the feed will contain only entry B (and NOT entry A).

 

5. Server finishes adding entry A to the collection, and returns the appropriate response to the client's POST of entry A.

 

6. Client GETs the collection feed again. Since entry B's app:edited is later than entry A's, and since the server only includes one entry per feed page, the client again will only see entry B, and not entry A, until it requests the second page.

 

My questions are:

 

(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?

 

(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?

 

(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?

 

(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?

 

Thanks,

Brian