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

On Sun, Sep 14, 2008 at 10:10 PM, Mark Nottingham <mnot@yahoo-inc.com>wrote:

>
> 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.


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 can imagine cases where redirection is key to efficient implementation of
resumability.  Here are some use cases:
1) A server farm where the majority of traffic is handled by essentially
diskless front-ends.  In order to support resumability, a server would need
to redirect the client to a separate pool of servers who are provisioned to
do the necessary caching.
2) A server farm where requests are load balanced across a pool of servers.
 Even if the load-balancing mechanism implements a reasonable affinity
mechanism, it's likely that that mechanism is just an approximation, and
that any particular request may end up on a variety of machines.  I can
imagine that an efficient implementation of resumability would be to ensure
the user connects to the same machine, where the request may be cached on
local disk.  Therefore, the resumable URI could be the name of that machine,
rather than the load balanced hostname.

I much prefer the ETag mechanism, in general.  I feel it is easier to
understand, and in some cases I think it would be easier to implement.
 Charles Fry created a reference implementation of this protocol in Apache,
and I think his changes were smaller with the ETag approach, due to
similarity to existing concepts in the server.  With that said, I can't
think of any cases where ETags would be necessary for ease of
implementation, so if I had to pick just one approach, I think URI's is the
way to go.