RE: II.6, non-reusable version URLs (was: comments on deltav-10.5 from Yaron Goland, Act Two)

A client will often care (very much) about whether it can store a
URL somewhere (in a document, as a property, etc.), and be able to
count on it to always identifying exactly that version.  If the
protocol does not guarantee that this will be the case, it will have
to use some additional info (etag, perhaps) for determining whether
or not this URL still identifies the same version.  But there are
many situations where all you can store is a URL, and there's no
way to say "and check that the destination of this URL still has
this same etag value".

Cheers,
Geoff


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]

It would be easy code-wise to use GUIDs in creating version URLs.  However
that's not the issue.  I'm not arguing whether this can be implemented
easily; it certainly can be.  I'm arguing whether it needs to be part of the
protocol specification.  Does it have any bearing on the protocol standard
whether or not a server reuses version URLs?  I think not.  Leave decisions
up to the implementors when they do not affect interoperability.  Or, give
me an argument why interoperability _suffers_ if the server reuses version
URLs.

lisa


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, December 12, 2000 4:08 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: II.6, non-reusable version URLs (was: comments on
> deltav-10.5 from Yaron Goland, Act Two)
>
>
> Note that a server can implement non-reusable version URL's
> fairly easily by extending the version URL with a GUID (such
> as would be used for a lock token).  The non-GUID part of the
> URL would be used to locate the resource and the GUID part of
> the URL would be stored as an implementation attribute on the resource.
> If the resource currently located at the non-GUID part of the URL
> does not have the GUID part of the URL, then the server would return
> a 404 on access to that URL.
>
> The benefit to the client (as Tim describes below) is significant
> enough to warrant serious consideration for adding it to the protocol.
>
> Lisa: does your server currently use GUID's for any other purpose
> (such as locking), and if so, would it be a problem to use them
> here?
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
>
> The term "version URL" simply means a URL that identifies a version.  In
> your example I'm not sure what you mean by "relative URL".
>
> Servers may support deleting individual versions (as well as the entire
> versioned resource).  It would be undesirable for servers to reuse version
> URLs since they represent a 'stable' reference to a particular
> state of the
> resource, and may be used as such by other persistent resources.  Clearly
> if the server reuses a URL that would be a bad thing in such
> circumstances.
>
> Tim
>
>
> "Lisa Dusseault" <lisa@xythos.com> on 2000-12-12 08:56:57 PM
>
>
> Can somebody clarify what this would mean:
>
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org On Behalf Of Geoffrey M.
> > ...
> > (II.6) Require that a version URL never be re-used after a version is
> >        deleted.
>
> Whether or not I agree with this, I find the phrase "version URL" to be
> ambiguous enough that I'm not certain what this comment is supposed to
> mean,
> so I'll start with an example:
>  - foo.doc is created
>  - foo.doc is made versioned and "foo.doc.__v1__" is defined as the
> relative
> version URL
>  - All of foo.doc is deleted
>  - foo.doc is created
>  - foo.doc is made versioned, NOW, according to this suggestion, the
> current
> version CANNOT be called foo.doc.__v1__ therefore is called foo.doc.__v2__
>
> Is that the intent?  if so, I'd have to disagree with this; although it
> might be desirable for a server to avoid ever having a version
> URL re-used,
> it ought not to be part of the standard.  I don't actually think it's
> relative to the standard, although it may be very relative to good server
> design.
>
> lisa

Received on Tuesday, 12 December 2000 20:46:07 UTC