W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: [google-gears-eng] Re: Deploying new expectation-extensions

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Mon, 15 Sep 2008 12:10:10 +1000
Cc: "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>
Message-Id: <7464C0EC-D4C1-4392-96BA-8C80B4112963@yahoo-inc.com>
To: Brian McBarron <bpm@google.com>


On 13/09/2008, at 12:53 AM, Brian McBarron wrote:

> I want to call out one point here.  In our proposal, the server is  
> in full control of the upload URI and the presence/absence of an  
> ETag.  This has several advantages:
>
> 1) The server can decide whether it is most convenient (from an  
> implementation point of view) to identify operations via a unique  
> URI and/or an ETag.
> 2) Regardless of the two potential mechanisms which can be used, a  
> server only needs to use one.  The server never has to "implement  
> all of them".
> 3) The client or intermediary will always have a URI to deal with,  
> regardless of whether it is unique or not.  Indeed, the client  
> doesn't have enough information to know if a URI is unique.
> 4) Thus, the only added complexity to the system of supporting  
> either/both methods, is that a client or intermediary must correctly  
> forward an ETag when it _optionally_ appears.
>
> To me, the overhead of (4) is very minor considering the power and  
> flexibility of (1).


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.

I appreciate that you're trying to foster adoption by making your  
proposal more flexible, but my experience is that this kind of  
flexibility is what puts protocols and extensions at greater risk for  
failure.

Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com
Received on Monday, 15 September 2008 02:11:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT