Resending since this didn't seem to make it to the list.
Forwarded message 1
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 --