RE: A non-forking server, precussor revisited.

The intent for "precursor-set" was that it capture the last "copy",
not that it accumulate all the copies.  But I agree that this is
not at all clear from the semantics of the COPY operation, so this
needs to be clarified.  The reason it is a set is to allow a 
client to add additional values if there has been a logical "merge"
to that resource.  But a COPY just sets it to be a single value.

A more general question:  I personally am not attached to the
"precursor" property.  Does anyone want to argue for keeping it in
the spec?  If not, I propose we get rid of it, since it seems to
be a source of confusion.

Cheers,
Geoff

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Thursday, June 14, 2001 3:06 PM
To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org
Subject: A non-forking server, precussor revisited.




In my first reading of the specification, I remind myself that I
probably don't fully understand the spec or how people envision that it
be implemented.

I note that there is support for both a forking and a non-forking
server. A server does not have to implement features that allow people
to 'fork' version controlled resources. I appreciate that. Some
situations and clients do require that capacity, but many other systems
would like to do a 'simple' versioning system and don't require this.

But it seems that the separation isn't clean. If I don't support
forking, UPDATE, or MERGE, then I see no reason at all to keep track of
precursor-set. 

Geoff said precursor-set was only one href, but I thought it was each
and every href that had ever been copied on top of a versioned resource
-- so it is an unlimited set of href's.

So I would strongly prefer that precursor-set be optional.  An
alternative would be that an implementation MAY not track precursor-set
and MAY set it equal to predecessor-set IF it doesn't support MERGE or
UPDATE.

Received on Thursday, 14 June 2001 18:06:36 UTC