List of DeltaV questions, issues, and extensions

I have been discussing a DeltaV implementation with
several colleagues at Oracle, and we have a list of
questions, issues, and possible extensions to the
protocol. I understand the Proposed Standard RFC is in
its final editing pass so there is very limited scope
for change in this RFC iteration. However, I will still
post these items for discussion in the working group.

Below is a summary of items I intend to post in more
detail ASAP.

Roy

--

Clarifications

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

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


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?


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).

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

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

Resolved

- Merge feature: Should the DAV:merge-preview report
  have the same response format as the MERGE and UPDATE
  methods? Resolution: it is acceptable the way it is
  in draft-18 - clients can request a DAV:merge-preview
  report to get more detailed information about a merge
  in a different format than the original MERGE.

- Activity feature: Add a DAV:auto-activity-checkin
  flag to MERGE from activities, putting the
  auto-activity-checkin behavior under client
  control. The use cases have to do with merging from
  an activity which has an interesting state you want
  to merge from your workspace, even though the
  activity is not yet done. Resolution: If the working
  group accepts Geoff's proposal for an
  auto-activity-checkin flag to activity merge, that
  would meet my requirement.


-- end of question, issue, and extension list --

Received on Friday, 5 October 2001 18:47:04 UTC