Re: re-use of version URL's (continued)

   From: "Mark A. Hale" <mark.hale@interwoven.com>

   I guess that I keep going back to the point that there may be occasions
   where 'non-stable' URL's are used.  These include:

	   - Reusable temporary version URL's
	   - Mutability concerns

Please review the "variant" proposal.  This gives you version-controlled
resources with server defined (but human meaningful) names.  The URL
for a variant is explicitly defined not to be stable.  Therefore a 
variant should both provide you with the "reusable temporary" and
the "mutable" resource you require.

   Even in a stable URL, we may even have mutability concerns as being
   discussed in the current threads. You reference that the above suggestion is
   not very useful, and the point is that it is not useful unless you have a
   stable version URL and systems may have others.  Please understand that I
   can appreciate the desire to have 'stable' version URL's from a long-lived
   client cache perspective.

There are two very different behaviors: immutability with a stable
name, and mutability with a re-usable name.  Saying that these are two
different "kinds" of a version is inherently non-interoperable, since
most code written to work with one of these behaviors will not work with
the other.

If instead we define two different kinds of resources (versions and
variants), and require that a server support one of them (versions),
then we get interoperability because every client can count on the
presence of immutable stable behavior on every server, and those
servers that want the "mutable, re-usable name" behavior have a
defined way to interoperate with each other (the variant option).

Is there anything you need to do that is not provided by the current
protocol with the "mutable version" option replaced by the "variant"
option?

Cheers,
Geoff

Received on Monday, 8 January 2001 07:25:37 UTC