mutable version resources (was: Re: Issues, Issues, ???)

On Wed, Dec 20, 2000 at 08:27:41PM -0800, Lisa Dusseault wrote:
>...
> > (2) Should version URL's be stable (i.e. cannot later refer to
> > something else)?
> No to what I think you mean.
> 
> I think you mean reusable, not stable. ( You can require version URLs to be
> stable: as long as a version exists, it will have the same URL.  It's when a
> version goes away that one starts to worry whether its URL may be reused.)
> 
> My plea is to let us manage our own namespaces.  Although it is not
> technically difficult to add a GUID to a URL, we consider that to be really
> ugly in a URL that we expect will be visible.
> 
> What if this requirement is dropped from the spec? Reuse may happen, but it
> will not be frequent.  The client can use ETags.  Interoperability is not
> threatened.
> 
> A client must deal with versions the way it deals with any resource:
>  - if it has never before retrieved the body, it has NO WAY of knowing
> whether the body has changed, and has NO REFERENCE POINT against which to
> compare that anyway!  It's meaningless to say that the content "shouldn't
> have changed" since a client which has never before seen the content can't
> tell the difference.
>  - When it does retrieve the body, it should retrieve the ETag.
>  - When it wants to see if the body has changed, it should compare the ETag.

If the server is advertising the version resources as "not mutable", then
who needs an etag?

Your position now *requires* every client to store etags related to version
resources. Just having that URL is no longer enough. (all related to the
weakening from MUST to a SHOULD)

It seems that your argument simply revolves around convenience. We've got
some pretty good use cases from Boris on simply using a URL to refer to a
resource. If that URL suddenly refers to something else... eek. And there'd
be no way to tell since the darn etag isn't passed along with the URL.

I think that your argument about "clients dealing with version resources" is
somewhat specious. I can argue that a client will fetch the version
resource, get an etag, and that it will continue to have that etag forever.
Further, a client won't "want to see if the body has changed" if it already
presumes the version resource is immutable. If you have some downlevel
browser, then it will check the etag, but will always find it unchanged.

Now... if a server advertises version resources as mutable, then yah:
clients damn well better start watching those etags. But I think the mutable
stuff blows, so I don't care that servers with mutable versions could screw
some clients :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 21 December 2000 04:18:52 UTC