Re: A problem with versioned collections

Let's do the easy one first: why do you need versioned collections?
(Saying why you need something is always easier than saying how you
will make it work :-).

If you make a (non-collection) resource revision immutable, one of
the things you freeze is any references it contains to other resources.
Those references will be invalid if you don't save the "state" of the
namespace that the containing collections provide.

This makes versioned collections essential for any application
that wants to version a resource whose semantics depend on other
resources that it "contains" or "refers to" (such as a book made
up of chapter resources, or source code that includes header resources.

I believe though that the solution is reasonably straightforward,
namely, that you use the same branching/labeling conventions for your
collection resources that use for your non-collection resources,
and then use a consistent rule/convention when selecting both the
collection and all its members.

This is one of the reasons why I believe the VPortal mechanism (which
selects a revision from just a single versioned resource) will not prove
to be very useful, while the dynamic configuration mechanism (which
provides a mechanism for consistently selecting revisions from an
entire collection) will be both necessary and sufficient.

Cheers,
Geoff

   From: John Stracke <francis@netscape.com>

   I see a problem with versioned collections.  Suppose /foo/,
   /foo/bar/, and /foo/bar/baz.html are all versioned.  Now,
   under the current protocol draft, you would refer to
   revision 1.5 of /foo/bar/baz.html by something like:

	GET /foo/bar/baz.html
	Revision-Id: 1.5

   Right? But that implies that, in all the different revisions
   of /foo/ and /foo/bar/, there can be only one revision
   history for /foo/bar/baz.html.  Suppose /foo/bar/ has two
   branches, and /foo/bar/baz.html was created separately in
   each of them; there should be no relationship between
   /foo/bar/baz.html in revision 1.5 of /foo/bar/ and
   /foo/bar/baz.html in revision 1.3.1.2 (that is, on a branch
   which forked off at revision 1.3).

   Either Revision-Id: has to take a path of revision IDs, or
   we have to get rid of versioned collections.
   (Personally, I'd vote the latter; I don't see what problem
   they're solving.)

Received on Friday, 9 October 1998 16:56:41 UTC