Re: Improving API for lists, or wildcarded schemas

["Dave Cridland [Home]" <dave cridland net>]

On Thu Jan 29 21:46:25 2004, Tony Houghton wrote:
> In <1075405273 4474 47 camel localhost localdomain>, Havoc Pennington wrote:
> > An argument for it though is that getting, modifying, and resetting a
> > list is current not an atomic operation, to avoid races you really need
> > a way to make an "append to list" or "insert into list" request.
>
> If you can use some internal locking functions it could be implemented
> simply by:
>
> lock
> read list
> delete/change item, or copy it for reading
> write list if it's changed
> lock

Or a conditional store, which seems to be the mechanism most used in 
IETF-land:

a) Associate a generation metadatum with each value. (Hey, I've always wanted 
to use the word "metadatum") In general, times seem very popular, the trick 
being that you make the millisecond portion always increase with every 
set/store operation.

b) Allow a set/store to optionally assert that the generation metadatum has 
not changed. Typically, with times, this is done with an "unchanged since" 
mechanism, so that clients can assert that the data is no newer than the last 
update they received from the server, and don't have to retain the generation 
metadata for all values.

There's (IMHO) big advantages over a lock metaphor:

1) A badly written (or compromised) client cannot deny service to others.

2) The server is simpler, since it needn't maintain locks.

3) No special handling is needed for a client-crash.

4) Clients can maintain the generation metadata across sessions.

Dave.