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(_at_)xpasc(_dot_)com> 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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf