Re: re-use of version URL's

Mark,

I think you need to grok the spec a bit more. To get the terminology and the
resource model nailed down a bit.

In particular:

*) version-controlled resources URLs can be anything that you want.
   Changing, unstable, human-readable, or line noise. There are no
   impositions whatsoever on those.

*) version resource URLs need to be stable.


In your email message below, I think you're potentially confusing the two.
In addition, "baseline" has a specific meaning within DeltaV, so you
shouldn't use that term unless you mean a DeltaV baseline (or else we all
get confused).

Concretely: you mention "version-controlled resource URL" twice, but that
isn't at issue here. You also mention "version URL" -- what resource type
are you referring to? version-controlled resources, or version resources?
There is also an unmodified "URL" in your message -- again, what does it
relate to? We only want to apply longevity to version resource URLs; we
don't care about version-controlled resource URLs.

Cheers,
-g

On Thu, Jan 04, 2001 at 05:14:37PM -0800, Mark A. Hale wrote:
> I appreciate the efforts to try to get an understanding and Lisa
> re-characterizing the human-readable issue.
> 
> Perhaps there is some common ground in the version-controlled resource URL
> concerns.
> 
> There appears to be agreement in the fact that we want URL's to have
> longevity.  Furthermore, this longevity applies to what I want to classify
> as resources that can be baselined.  (Since I am new to WebDAV, I hope that
> I am not opening up a can of worms by using the term 'baseline'.  In the
> context here, it is a resource that is stable and has longevity).
> 
> There are implementation possibilities where version URL's can be reused. (I
> am not trying to judge the quality of the implementations and the impact on
> either client of server functionality.  Merely an acknowledgement that these
> implementations are feasible.) The example I posted earlier was centered on
> the concept of a temporary space.
> 
> I propose that we instead use something to the effect 'MUST NOT re-use
> version-controlled resource URL's for resources which can be baselined'.
> 
> I either made things better or worse - any suggestions?
> 
> 	Thanks,
> 
> 	Mark
> 
> 
> 
> 
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Thursday, January 04, 2001 4:06 PM
> > To: Geoffrey M. Clemm; ietf-dav-versioning@w3.org
> > Subject: RE: re-use of version URL's
> >
> >
> > I think I agree with Mark and will try to clarify for him...
> >
> > > In particular, you have a cheap way of guaranteeing unique version
> > > url's by tacking a uuid to the end of the implementation name of
> > > the object in your store.  This gives you a stable name for a version.
> > > In addition, you have human meaningful names for versions, by
> > > combining version-controlled resource URL's with version names and
> > > labels.  So it looks the protocol gives you both stable names for
> > > versions and human meaningful names for versions.
> >
> > Yes, you get stable URLs (names) for versions.
> > Yes, you get human meaningful names, but only really for
> > version-controlled resources.
> >
> > The phrase "human meaningful" is probably where the disconnect is.  If
> > you consider the following human-meaningful, then you're right.  But I
> > suspect Mark doesn't consider the following particularly usable.
> >
> > http://www.server.com/version-space/path/filename.ext/version2/UUID10938
> > 478691283
> >
> > Lisa

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

Received on Thursday, 4 January 2001 20:26:19 UTC