On Sat, Mar 7, 2009 at 5:00 PM, Antony Blakey <antony.bla...@gmail.com> wrote: > > On 08/03/2009, at 11:14 AM, Damien Katz wrote: > >> The problem is if there is a network error, a client has no way to if a >> POST commit was successful. The success or failure response can get lost, >> and the id of the document is completely unknown to the client. > > This is a different problem than the double post - would the same problem > not occur if the client failed? e.g. if there's no way of finding the > resultant document, then the failure modes seem symmetric. >
Client failure has to be expected. A POST is fire-and-forget. If you use it right (as we strive to) you can even make it seem idempotent. Tighter coupling between the client and server is the last thing we need. > Maybe a generic solution could > be to allow a client supplied UUID in the request, which is retained in the > server for some short time (in network terms) to make POSTs generically > idempotent over some window? > Setting up window agreement is not the sort of problem I think CouchDB should strive to solve. It may be that CouchDB is well suited to it, but I think the proper point of implementation is at the application level. CouchDB aims to be a sort of lowest-common denominator. If you implement is as a CouchApp that emits JSON and maintains server closures in JavaScript, you'd pretty much have what you need, and it'd be replicateable across raw CouchDB nodes. Chris -- Chris Anderson http://jchris.mfdz.com
