Brian,
As far as I can tell, the proposal places the burden for ensuring atomicity entirely on the server. However, PATCH is explicitly not idempotent. If a client issues a PATCH, and the server executes the PATCH, but the client then fails to receive an indication of success due to an extraneous network glitch (and TCP reset?), then what prevents the client issuing the same PATCH again? In other words, absent a two-phase commit, there appears to be no transactional integrity.
I think Lisa should respond to this as well. One of the issues here is that I believe there is an assumption that there will be some external means to know that in fact the PATCH succeeded, like for instance retrieving the impacted web pages and comparing results. In thinking about this again, however, perhaps that may not be sufficient, if for instance, PATCH is used for purposes of a side effect that is not easily verified. At that point you probably want something a kin to a transaction ID where you can check against that ID to deterine if it had succeeded.
An alternative view, however, would be that for a specific object type where that is important, one could imbed such a transaction ID somewhere. That's not so easy for common objects we retrieve today (you would have to add some sort of meta tag into an HTML doc, and who knows what you would do with images), but since those objects could easily be retrieved and compared, they're not the problem.
Put this another way: I don't think PATCH is a replacement for all the network database protocols and mechanisms that exist today, but simply closer to what it is named: a means to patch one or more objects.
Eliot
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
