- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Mon, 15 Sep 2008 12:10:10 +1000
- To: Brian McBarron <bpm@google.com>
- 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>
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 UTC