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 [EMAIL PROTECTED]
