Re: Sorting by app:edited & Concurrency

[Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx>]

On 14/11/07 12:44 PM, "Brian Smith" <brian@xxxxxxxxxxxxxx> wrote:
> 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.

presumably this includes A's atom:edited value of 12:34.0Z.

> 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. 

Technically, the client really should page backwards until it sees at least
one entry with an atom:edited value *earlier* than the last known edit.
Consider the case of there being 11 exactly simultaneous updates and only 5
entries per page to understand why. This doesn't eliminate the issue you've
described though.

But where's the problem?

While the representation of entry A which is returned in step 5 may be
incomplete, so might the representation of entry A which is returned (on
page 2) of the collection feed. The client is well advised to directly
request the resource located at link[@rel='edit']@href and use that as the
basis for editing (and then also to use the ETag supplied in response to
that request when PUTting a change).

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

I would suggest the server should assign the current time at the *end* of
processing, not the time at the start of processing. If the server wants to
immediately return something to the client in response to the post (and not
wait for processing to complete), then return an edited value as of that
moment, and then *also* update the atom:edited value as of when the entry is
added to the collection. Of course, if processing is held up for effects not
visible in the entry resource this would result in an unnecessary churn ...
however if the entry as available in response to the POST has no visible
differences from the entry available after processing then it matters not if
they see the entry in the collection feed or not ... unless the entry of the
POST response is of a different profile of the same resource as the entry
representation in the collection feed, in which case you do want to go
looking for it, alas. Final word though: you can't rely on the
representation of the entry in the POST response or in the collection feed,
as noted above .. the client should still fetch the atom resource at
link[@rel='edit']@href.

e.