I agree that a mechanism for atomicity would be nice. I also agree that POST is in a sense a superset of PATCH. So if I want a mechanism such as 2-phase commit I really would want it for POST as well as PATCH, more so really. So I don't want to see the issue addressed in PATCH if it is addressed at all. At most I want a not in Lisa's draft to say 'hey we don't do this'. For example, one can imagine a new HTTP header Transaction-ID and a mechanism for querying the status of missed acknowledgements. This would be available for PUT and POST, not just PATCH. I don't think I would want a traditional 2-phase commit, I would prefer something similar to sliding windows so that I can pipeline requests and avoid the need for responses to be synchronous. For example, the request might have the following header Transaction-ID: we3292j239023i9i9== 42 Transaction-Rack: we3292j239023i9i9== 36 Where we3292j239023i9i9== is a pseudo-unique transaction stream ID. The transaction IDs advance by 1 each time. The client is specifying that it has received notice (reacknowledgement) of all transaction IDs it cares about up to number 36, the server can thus drop all state associated with any transaction number 36 or less for that stream. The response might have the following header: Transaction-Ack: we3292j239023i9i9== 37-39 41 This is loosely NNTP format from memory. The server has completed transactions 37, 38, 39 and 41. Transactions 40 and 42 are outstanding. What this approach does not do of course is to manage the status return. A transaction can be closed but have failed.I am not really sure you would want to bind that into HTTP protocol. But if you did it would be with a new method (STATUS) that allows you to pull up the response code for your previously declared transaction. On Fri, Nov 13, 2009 at 11:13 PM, David Morris <dwm@xxxxxxxxx> wrote: > > > On Fri, 13 Nov 2009, Roy T. Fielding wrote: > >> >> Yes, and that is exactly what would happen even if HTTP supported >> full two-phase commit, with all of its painful consequences, if the >> response to commit was lost. This is an application problem, not >> a protocol requirement. It can be "fixed" (to the degree that any >> fix is possible in a distributed system) by providing the client >> with a status resource within the same page as the SUBMIT, such >> that the client can see the change in server state when it takes >> place even if the specific 200 response is lost. In other words, >> provide the client with the information necessary to check the bill >> before the final transaction is submitted. >> > > It can also be checked on the server is a serial number is included > in the POSTed data which can be used to determine if the original > post was already processed. > > Dave Morris > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf