Re: Versioning goals doc

Jim Whitehead wrote:

> Chris Kaler writes:
> > - Under "Definitions" : I don't think it is necessary that abstracted
> > versioned resources do not exist.
>
> This is a good point. I feel the last sentence in the definition of
> "abstract versioned resource" can safely be omitted without losing the
> essence of the concept.

OK, I've changed that sentence to "Abstract versioned resources may not
actually exist as resources; it is a concept that makes it easier to discuss
versioning".  How's that?

> So, the URL of the
> first revision of "example.html" might be "example.html?ver=2.0".

(Side note: that's a bad syntax, since a Web page can include JavaScript that
reads the ? arguments.  Compare <http://www.thibault.org/dav/example.html> and
<http://www.thibault.org/dav/example.html?foo=bar>.)

> Chris Kaler writes:
> > - Under "Goals" : #5 is tied to an implementation.  Why doesn't #2 cover
> > this?
>
> I'm not very fond of this goal either.  It's a standardized URL munge.

Yes, but it's one with precedent: consider the URL munge of "if you have a
collection http://example.com/foo, and it contains a resource named bar.html,
then that resource's URL is http://example.com/foo/bar.html".  A version graph
contains references (in the general sense, not necessarily in the Advanced
Collections sense) to revisions; why shouldn't it use a similar syntax for
containment?

> John Stracke writes:
> > Because all that #2 says is that there exists a URI for each
> > revision; you may have to issue a request to find out what it
> > is.  Being able to build a URI directly makes it possible to
> > publish links to revisions.
>
> But, once you have discovered the URI for a prior revision, then you can
> always link to that revision.

Yes, provided that the server doesn't move the revisions around.  Besides,
that's assuming that you're a human, writing a static page.  If you're a CGI
script, and that discovery requires an HTTP request and maybe an XML parse,
that's more complicated than it needs to be.

The Holy Grail that I have in mind is that a Vgraph should be a collection.
The collection would contain two types of member resources: revision IDs
(references to revisions), and labels (references to revision IDs).  These
member resources, since they'd exist independently of the revisions they point
to, could have their own properties.  Some of these properties could be
standardized (e.g., DAV:predecessors, DAV:successors, and DAV:variants to
represent the DAG; and DAV:comment to store a note submitted at checkin),
others could be defined & used by individual clients.  You could use a PROPFIND
to get a resource's neighbors (predecessors, successors, and variants), or to
list all the resources in the Vgraph, with their neighbors and the revisions
they point to (DAV:target).

> The URL string manipulation convention you're
> proposing is merely a shortcut for avoiding this first step of discovering
> the URI of the revision.

It's a pretty useful one, though; it saves us from having to define any new
methods, and it enables a CGI script to generate links to revision references
without having to include HTTP client code to do the query itself.

> Chris Kaler writes:
> > - under "Goals" : #6 is also tied to an implementation.  What is the
> > scenario?  A requirement that says something like, "You must be able to
> > search version history" is valid.  Is that what you meant?
>
> I agree that this is still too implementation-specific, since I can imagine
> potential implementations where a version graph is not a collection,

But you could still have the "search a collection" method(s) apply to it, even
if it isn't really a collection.

To put it in OO terms: if the DAV server supports collections that implement
the Searchable interface, and it is possible to search a Vgraph, then a Vgraph
should implement the Searchable interface.

I've changed the text from "search a version graph as a collection." to "search
a version graph as if it were a collection"; how's that?

> Chris Kaler writes:
> > - Under "Goals" : There are some aspects of a revision that must
> > be mutable. For example, changing the security.  I think this is what you
> > meant by your explanation paragraph, yes?
>
> Live properties in general are tricky here.  I think it makes sense to limit
> freezing of properties to dead properties only.

Right, OK, that's a good way to put it.  The goal now reads:

8.  Revisions are immutable: once a revision has been checked into the
repository, the revision can never be deleted; and its contents and dead
properties can never be changed.

--
/======================================================================\
|John (Francis) Stracke    |My opinions are my own.| S/MIME supported  |
|Software Retrophrenologist|===========================================|
|Netscape Comm. Corp.      |I'm not a bibliophile, I'm a bibliophiliac.|
|francis@netscape.com      | Put me in a bookstore, & my wallet bleeds.|
\======================================================================/

Received on Friday, 25 September 1998 16:41:02 UTC