On 2/13/06, Tim Bray <[EMAIL PROTECTED]> wrote:
> In general I agree, although I would expect the WordPress gang to
> have more hands-on experience with what works and what doesn't than
> almost anyone else.
I'd prefer if they participated here directly, instead of by proxy,
then I could ask them about the other protocols they've
tried to implement with PUT/DELETE that they have had
problems with.
> But for the record, in this case I don't believe that tunneling
> updates and deletions through POST erodes Webarch in the slightest.
You would be mistaken, here are some examples:
1. My client implementation uses httplib2[1], my caching http
client library. Because an entry is edited via GET, PUT and DELETE
to the same URI I can track that all through the cache, invalidating
the cache when a PUT or DELETE are done to an entry. If you route
PUT and DELETE through POST to another URL then you kill
that advantage.
2. My client library also implements Section 3.2 of
"Detecting the Lost Update Problem Using Unreserved Checkout"[2].
My client library can do that because GET and PUT are generic
methods that act on resources with well defined semantics. This
will work for any HTTP resource, not just an APP service. By tunneling
PUT and DELETE through POST you kill all those advantages.
Which leads to #3.
3. In your I-D you will have to cook up your own solution for the lost
update problem or explicilty acknowledge that updates could
be lost.
[1] http://bitworking.org/projects/httplib2/
[2] http://www.w3.org/1999/04/Editing/#3.2
-joe
--
Joe Gregorio http://bitworking.org
