RE: List of DeltaV questions, issues, and extensions

   From: Roy Seto [mailto:roy.seto@oracle.com]

   Resending since this didn't seem to make it to the list.

That is strange ... Peter seems to be having similar problems with only
some of his posts making it through.

   Clarifications:

   - Version-controlled collection feature: Does eclipsing a
     version-controlled collection eclipse its members as well?

Yes.  A collection consists of a set of bindings.  If you eclipse a
collection with a non-collection, there are no members there.  If you
eclipse a collection with a different collection, it is the bindings
of the eclipsing collection that you see.

   - Activity feature: Is there an interoperable way to "close" an
     activity (that is, prevent any more checkouts or checkins in that
     activity)? Followup: if not, how much demand would there be for
     standardizing this concept?

I suggest we should soon start a follow-on "change request"
working group (we could start under the auspices of the
WebDAV working group).  In particular, we would then discuss
various states that an activity could be in, and how to
standardize transitions between those states (is PROPPATCH
enough?).  Minimally, we could decide on some standard
XML element for the state field of an activity, and a few
"standard" state values.  Perhaps a BOF at the Dec IETF?

   Is This A Bug?

   - Baseline feature: Is it possible to construct a workspace which
     contains multiple VCR's with different DAV:checked-in versions
     for a given VHR by doing a MOVE of a VCR from one
     baseline-controlled collection to another, and then UPDATING the
     VCC's for those BCC's?

I think the intent of the spec is clear (only one VCC for a given
version history in a given workspace), but I agree that
we are missing a postcondition on the MOVE operation.  A
workspace is required to have only one VCR for a given version
history, so any operation that would violate that constraint (which a
MOVE could) should fail.  Similarly, we should clarify in the extended
UPDATE semantics, so that it is clear that the UPDATE of a VCC causes
an existing VCR to be bound into a collection, if there already is a
VCR for a given version history in the workspace.

Since these semantics can be inferred from the global statement
that a workspace can only contain one VCR for a given version
history, I think this clarification can wait for the next rev
of the spec (not that you were suggesting otherwise).

   Possible extensions

   - Activity feature, update feature: Define the semantics of UPDATE
     where the source is an activity. Use case: Provide a performant
     standard way for clients to ensure that the members of a
     workspace select the latest version of an activity. This is key
     to support the concept of merging to an activity (by merging to a
     workspace which selects the latest versions in that
     activity). (Note: ideally, this extension would also modify
     generic UPDATE marshalling so the DAV:update element had a
     DAV:source child element, like MERGE does, instead of a
     DAV:version element. An activity resource is not a version
     resource).

I find this not very compelling.  An activity is a logical
change set.  Simply "setting" some of your versions to those
selected by some change set sounds like a great way to 
hide parts of existing change sets, and making your workspace
inconsistent.  So "MERGE" on an activity makes sense to me,
but "UPDATE" does not.  Perhaps you could develop the use case
in some more detail?

   - Merge and update features: Add a flag to make DAV:response
     elements of UPDATE optional, and to make DAV:response elements of
     MERGE optional for targets modified by postcondition
     DAV:descendant-version. Use case: improve response times when the
     request-URL of the MERGE or UPDATE has an extremely large number
     of members whose DAV:checked-in versions are modified by the
     MERGE or UPDATE, and when the client's caching policy will not
     benefit from the DAV:response elements enough to outweigh the
     cost of adding the DAV:response elements to the response body.

A server has to compute all of this information anyway (to do the
update), so all one would be saving would be the cost of sending the
info back (which is rather small chunk of information, compared to
what the net is set up to pass around).  But if this really turns out
to be an issue in practice, it certainly would be easy to add such an
extension.  Are you getting actual performance numbers on this that
concern you?

   - Autoversioning (extension), baseline feature (use case): In
     Section 3.2.2, change the EMPTY elements in the DAV:auto-version
     property values to ANY, enabling DAV:checkin and DAV:checkout
     elements with default checkin and checkout options for the
     autoversioned VCR to be applied at auto-checkin and auto-checkout
     time. Use case: multiple workspaces share the same
     DAV:current-activity-set and the same DAV:checked-in baselines
     for their version-controlled configurations, and those VCCs'
     DAV:auto-version properties are DAV:checkout. There is a problem
     because baseline-controlled members of those workspaces cannot be
     checked in even if they are for different version histories -
     only the first workspace can auto-checkout its VCC unreserved in
     the shared DAV:current-activity-set.

That sounds pretty reasonable to me.  I might just give these their
own property names though, so that it is easier for a client to
determine if this option is supported.

Cheers,
Geoff

Received on Tuesday, 2 October 2001 23:27:19 UTC