RE: Sorting by app:edited & Concurrency

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Joe Gregorio wrote:
> > 1. Client POSTs entry A. Server chooses 2007-11-12T12:34[:00]Z 
> as entry A's 
> > app:edited property.
> 
> The value of app:edited for a new entry is the time at which 
> it was created. How can an entry be created and yet not 
> appear in a collection feed?

That is part of what I am asking in question (c): does the collection
feed always need to be up-to-date, or is it allowed to lag behind?

The creation of an entry is going to take some time. I agree that
app:edited should be a timestamp as close to the end of the creation
process as possible. 

In my server, when an entry is POSTed or PUT, the server writes the
entry to disk exactly as it will be returned in responses. In
particular, the app:edited element is written to a file, so, I need to
know it before the file is completely written to disk. I also store the
app:edited value in the file so that I don't have to rely on any files'
mtime.

My server also implements every POST, PUT, and DELETE as an atomic
operation. An entry cannot appear in the feed until it is committed. I
have to do a few filesystem operations in order to commit an entry. On a
slow/busy webserver/network/filer combination, this is definitely enough
time to notice this kind of ordering issue.

I can rework my implementation to serialize all POST, PUT, and DELETE
operations enough to ensure that timestamp generation and commits are
not interleaved, but I'd like to avoid that if possible.

Regards,
Brian