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

Re: re-use of version URL's

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 4 Jan 2001 16:06:48 -0500 (EST)
Message-Id: <200101042106.QAA28473@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Mark A. Hale
   > 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
   > ...
   > 
   > 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.

"Meaningful" names are inherently in conflict with "stable" names
(i.e. names that always identify the same state), since over time, you
need to reassociate "meaningful" names to new resources and new
states.

The protocol provides version-controlled resource URL's,
the "version-name" property, and labeling as mechanisms to
provide meaningful names.

The protocol provides version URL's to provide stable names.

If we allow version URL's to be unstable, we lose the one
part of the protocol that provides stable names, and duplicate
other parts of the protocol that already provide meaningful
names.  That doesn't sound like a good tradeoff.

So in Marks example, the protocol would have you identify
"http://someWebDAVServer.com/write.c" as a version-controlled
resource, and "/temp/synchronous/1.0" as a version-name.

Now your client could expose these names however it wants; in
particular, it could make it look to a user like the version-name
extends the version-controlled resource hierarchy (in ClearCase, we do
just that), but this can then be marshalled on the wire as a
version-controlled resource URL and a version-name, and keep
the version URL as a stable name (with all the benefits identified
by Preston and others).

Cheers,
Geoff
Received on Thursday, 4 January 2001 16:07:38 GMT

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