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

On Sep 19, 2008, at 7:28 AM, Charles Fry wrote:
> A few more thoughts on URLs and ETags:
>
> - While it isn't clear in the examples on the wiki page, the initial
> handshake is optional. In other words, it represents one extreme end
> of the protocol, but the primitive requirement is that unique
> identifier (whether URL or ETag) be obtained. This could very well be
> present in an HTML page, for example, allowing a resumable upload
> without the initial handshake.
>
>  - Regarding ETags vs. URLs, one point of reference for me is CGI
> scripts. A single CGI script running behind a fixed URL should (in my
> mind) be able to perform a resumable upload, but this would require a
> unique identification mechanism other than the URL.

That isn't relevant -- any CGI script (and just about any part of a
server's URI space) can be overlapped as many times as you want.
In any case, ETag is not a unique identifier.

I already explained how to do this functionality in
<mid:3173C7D0-7078-480E-9B99-E174AD2001DA@gbiv.com> on Apr 4.

The ETag examples you provide don't make any sense.  Etags only
have meaning within the scope of a resource's current representations.
If you are posting to a service that has no corresponding resource
mapping, the etag in response must correspond to the etag that you
would have received if the request were a GET on that service.
In essence, this allows a service to be versioned, though such
interfaces are not typically used on the Web because we prefer to
use backwards compatible services rather than strict version coupling.

So, the short answer is that only the URI solution fits within
the current web architecture.

....Roy

Received on Friday, 19 September 2008 16:02:26 UTC