Re: II.6, non-reusable version URLs

Subversion will have persistent, unique, non-reused URLs for the version
resources. They will look something like:

    http://www.webdav.org/repo/$svn/ver/56.3

No sweat :-)

Cheers,
-g

On Tue, Dec 12, 2000 at 06:18:13PM -0800, Lisa Dusseault wrote:
> I'd never recommend to any client to stop using ETags for this purpose!
> Sounds dangerous.  The client always ought to rely on the ETag to see
> if things have changed.  Require clients to use ETag for what it was
> designed, and further, require clients to be able to deal with re-use
> of version URLs.  It's good medicine.
> 
> Now, my second line of defense for this is usability.  Assuming somebody
> will want to put version links as URLs in web pages, or in emails, then
> it would be more usable to at least be able to construct short, possibly
> meaningful version URLs.  The use of a GUID will preclude this.
> 
> FWIW, here's what a Xythos Version URL for a real file looks like:
> http://www.sharemation.com/~milele/public/advanced-status-reporting.htm?vers
> ion=1
> 
> 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 5:45 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)
> >
> >
> > 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

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

Received on Tuesday, 12 December 2000 23:46:11 UTC