RE: Versioning goals doc

I am concerned that this document seems to reflect a specific implementation
rather that the functionality requirements for versioning.  You'll see this
reflected in my comments below.

- Under "Definitions" : I don't think it is necessary that abstracted
versioned resources do not exist.  In fact, I don't really see the point of
this term.  It really assumes you have some Vgraph like implementation.  

- Under "Definitions" : The Vgraph is defined as an artifact of a proposed
implementation.  We need to keep this document focused on the scenarios
being addressed and the problems it must solve (the requirements).  I can
see the point of an abstraction called a "version graph", but you seem to be
defining the Vgraph.

- Under "Goals" : I disagree with #1.  We are trying to define a standard
that meets the requirements of the Internet community.

- Under "Goals" : #5 is tied to an implementation.  Why doesn't #2 cover
this?

- 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?

- 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?

- Under "Goals" : #11, again this is tied to a proposed protocol.  What is
the scenario you are trying to address?  "It must be possible to determine
the predecessor and successor versions" ?

- Under "Goals" : #12, again this is tied to a proposed protocol.  We should
say something like "It should be possible to determine the version history
in one operation".  However, I believe that this is not a practical
requirement as it is possible for the version history to be spread across
multiple servers and a single server shouldn't be required to track it all
down.  Nor do I expect that a client wants to wait for it.

- I didn't see anything about automatic versioning for HTTP/1.1 clients.
Did I miss it?  (which is entirely possible).

- Personally, I'd like to see a goal that we make it easy for clients to
interact with DAV servers that support versioning.  This may be somewhat
contentious, but I believe that we need to make it easy for clients at the
expense of adding some complexity to the servers.


Chris

-----Original Message-----
From: John Stracke [mailto:francis@netscape.com]
Sent: Wednesday, September 23, 1998 5:01 PM
To: WebDAV WG
Subject: Versioning goals doc


I've been working on a versioning goals doc (with input from Jims Amsden
& Whitehead); it's at <http://www.thibault.org/dav/version-goals.html>.
Note that it's not self-contained; it's more of a diff from the
versioning sections of RFC-2291.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | Don't anthropomorphize computers.       |
|francis@netscape.com      |   They don't like it.                   |
\====================================================================/
New area code for work number: 650

Received on Thursday, 24 September 1998 16:08:33 UTC