- From: Mark A. Hale <mark.hale@interwoven.com>
- Date: Thu, 4 Jan 2001 11:56:36 -0800
- To: <ietf-dav-versioning@w3.org>
> 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 UTC