W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: re-use of version URL's

From: Mark A. Hale <mark.hale@interwoven.com>
Date: Thu, 4 Jan 2001 11:56:36 -0800
To: <ietf-dav-versioning@w3.org>
Message-ID: <FCEJIPPGHGNPMFLDIMEFAENFCHAA.mark.hale@interwoven.com>
> On Thu, Jan 04, 2001 at 10:02:56AM -0800, Preston L. Bannister wrote:
> > From: Mark A. Hale
> > [snip]
> > > At this time, Joe wishes to explore a synchronous and
> asynchronous write.
> > > He decides to use version control in a temporary space in which this
> > > particular server has the version URL's:
> > >
> > > 	http://someWebDAVServer.com/write.c/temp/synchronous/1.0
> > > 	http://someWebDAVServer.com/write.c/temp/asynchronous/1.0
> > >
> > > And after time, Joe has the following:
> > >
> > > 	http://someWebDAVServer.com/write.c/temp/synchronous/1.8
> > > 	http://someWebDAVServer.com/write.c/temp/asynchronous/1.10
> > [snip]
> >
> > > At a future time, Joe may decide again to try another synchronous code
> > > sample with the following version:
> > >
> > > 	http://someWebDAVServer.com/write.c/ver/1.20
> > >
> > > put into the following temporary space:
> > >
> > > 	http://someWebDAVServer.com/write.c/temp/synchronous/1.0
> > >
> > > In this case, there is a logical re-use of the same URL with a
> > > 'meaningful' URL address for use by Joe.
> > >
> > > I will not argue that this is how we implement our systems
> but I do think
> > > that the possibility for this kind of implementation should not be
> > > restricted.
>
> I think it should. It would be very easy for that system to include 1.20
> into the temp space's URL. That would effectively avoid reuse.

Yes, and we could maintain a system that remembers everything and becomes
slower with time and consumes more memory.

The original use case I presented had the following:

	In addition, the temporary spaces are completely deleted and are not
	maintained anywhere in the server.

This is part of the story I presented and is a highly reasonable scenario.

> And note that we're talking about version URLs here. They don't have to be
> nice at all. All of the URLs could be formatted like:
>
>     http://www.webdav.org/$versions/cc46d79e-d11d-b211-8658-f8d684ddefeb
>
> Yes, the hierarchy is nice, but it is just too easy to create
> unique version
> resource URLs.

In this context, the argument is not about whether or not we can assign
unqiue URLs.  In fact, I stated in the original e-mail that we can do just
that.

There are equally as many reasons on why we want to have meaningful URLs.

> > Say Joe sent you an email asking you to look at his working copy:
> >
> > 	http://someWebDAVServer.com/write.c/temp/synchronous/1.1
> >
> > If you were a bit tardy reading your mail and Joe is working on
> > the second try, you will be looking at the second attempt.
> >
> > This could be quite confusing.
> >
> > I suspect you don't *ever* want a versioning service that to an
> > end user "sometimes" delivers the wrong version!
>
> Exactly!
>
> Not to mention historical recordings of the work, old web links, whatever.

On the surface, you would seem quite correct.  However, the use case is for
a temporary working space for the user to operate in.  We should instead
consider the semantics of what it means to be a temporary workspace (would
you keep a file in /tmp on a UNIX box for another user?).

As a caveat, I need to add that I am not advocating this is the way we build
a server.  However, I feel this is a reasonable use case in its bounds that
presents a reasonable doubt that the hardened MUST should be used.

	Thanks,

	Mark
Received on Thursday, 4 January 2001 14:54:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT