- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 15 Sep 2008 16:16:04 +0200
- To: "Brian McBarron" <bpm@google.com>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "Julian Reschke" <julian.reschke@gmx.de>, "Charles Fry" <fry@google.com>, gears-eng@googlegroups.com, "Alex Rousskov" <rousskov@measurement-factory.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Am 15.09.2008 um 15:41 schrieb Brian McBarron: > >On Sun, Sep 14, 2008 at 10:10 PM, Mark Nottingham <mnot@yahoo- > inc.com> wrote: > >[...] > >Sorry, I *really* don't buy that. You're pushing more complexity > and ambiguity (see previous post) onto the clients, which >history > shows are more numerous, harder to implement and easier to stuff > up. On the server side the difference between using >URIs and using > ETags is more a matter of style than implementation complexity. > > Rather than waving hands about history, let's keep the conversation > a bit more pragmatic. If we can find agreement that one of the > models is sufficient, I'd be happy to narrow the specification. I agree with Mark that optional features/alternate behaviours make clients more complex and results usually in poor interoperability. But, boy, do I dislike ETags. They are like visits to the dentist, necessary but no pleasure. How would a client cancel an upload scenario which just uses ETags? (With temp URIs the obvious solution seems to be a DELETE on that uri. I sure would feel uncomfortable with a DELETE/if-match: Etag on the original POST target...) //Stefan -- <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782
Received on Monday, 15 September 2008 14:31:32 UTC