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