Next message: Clemm, Geoff: "RE: Review of 06"
Message-ID: <398146D100002999@mail0.mailsender.net>
Date: Mon, 7 Aug 2000 21:44:10 +0100
From: "Tim Ellison" <tim@peir.com>
To: "Delta-V" <ietf-dav-versioning@w3.org>
Subject: Minutes from the Working Group Meeting, 2-Aug-00
Minutes from the Delta-V Working Group Meeting
held 3:30pm - 5:30pm Wednesday 2 Aug 2000, IETF Pittsburg, PA
- Participant suggested that the server should have a better understanding
of the resource types stored on the server (i.e. formats) to simplify the
versioning problem. For example, binariews can't (in general) be delta
encoded, and text can.
Discussion of the 'agnostic' approach to resource type -- and what delta-v
is trying to achieve.
- Discussion of granularity and scope of versioning, one resource per versioned
object, or multiple resources per object. Not interpreting resources to
version control 'links' or compound documents. delta-v is applicable to
individual resource level versioning.
Is there any representation in delta-v that captures inter-resource relationships
(links) Answer: No. Are additional parts of URL (i.e. fragments, query
strings preserved)?
Answer: yes, the actions are against the resource, but the whole URL is
relevant. Byte ranges in range requests preserved?
- Question regarding reuse of existing error codes. Response was that is
done for versioning unaware clients to understand what happened, and because
it is recognized that there is a limited number of new codes left to define.
- Observation that now we can see that the work on versioning is 'for real'
this work should be better known within the IETF. Maybe broadcast a ietf.org.
Question, are we working with W3C to ensure good adoption? Answer that
there is good vendor participation and interest in the work.
- MKWORKSPACE 13.1 has premature sentence termination.
- Explanation regarding initializing the content of a workspace. Requires
a better explanation in the motivation document/book of why.
- Has the working group considered the use of checksums to determine if
a resource already exists, say on the local hard drive? Response was that
the history resource on the server is used to show how resources are 'shared'
between distinct URLs, and could use e-tag etc. to determine equivalence
on the client.
- Discussion regarding the coverage of implementation 'tricks' that can
be used to implement delta-v, and how they are envisaged to cover RCS and
comma-v file for a 'local' server implementation, thru CVS, up to high end
multi-site caching CMS -- all using the same protocol. Observation that
collaborating machines across the world could use the protocol for distributed
systems. The working group compared many different VCM systems when designing
the protocol.
- Question: Is there any server now available for testing delta-v? Answer:
Nothing is publicly available.
- Can you roll back a server state or must you checkout and checkin again
to move back to a previous state?
You can restore to the state of a baseline en masse, or use SET-TARGET to
specify the selected revision.
- Deleting a revision is left server defined. Discussion of various options
for DELETE on a versioning server. Agreed that this will be an interop
issue.
- Observation that the goals are ill-defined in the protocol document.
How does it relate to collaboration support-and what about versioning the
web?
Response is that delta-v will probably not to represent the 'state of the
web'; rather for private corporate use. A different response was that ACLs
will allow broader access to storing the state of the web, with restricted
visibility of history.
- Observation that versioning the 'active web' would be possible, i.e.,
running programs on distributed systems, SNMP, or router.
- Parallel development and merging; how do you merge binary content?
Response: there is no requirement to merge resource content, conflicts are
flagged as requiring manual intervention.
- Overview of MERGE semantics. If you merge into something that is checked-out
already, that should be flagged as a conflict -- make that more explicit
in the protocol doc.
- Predecessors can be modified using a PROPPATCH on the predecessor set,
for servers that support that.
- Should the checked out revision be remembered as a distinguished predecessor?
Divided opinion amongst group.
- In activities, all revisions must be on a single line of descent. Clients
would use an activity to show the distinguished predecessor relationships
between revisions related in this way.
- Discussion about the meaning of activities. Worked through some examples
of checkin, and checkout in activities.
- Further discussion about a distinguished predecessor. The predecessor
set is ordered, so clients are free to imply an order if they choose to
do so. Protocol doc. should point this out.
- Question regarding spreading the history of a versioned resource across
multiple servers. Assuming that different revisions of a versioned resource
can be on different servers. Response was that such situations are not
prevented by the protocol specification, a revision URL is a URL i.e., that
resource can be located anywhere. Expect that workspaces will be on different
machines.
- Reminder that we are coming up to the last call, request that you get
the fixes in now.
- Question: Are there any recommendations made about notifications or polling
frequency to determine when history has been modified on the server. Answer
is that notification is not part of delta-v, but may be in the realm of
others, look at Instant Messaging (IM).
- Is this compatible with the delta encoding internet draft?
Should be compatible, may need to send back a revision URL as an e-tag supplement.
Maybe delta-encoding could make more use of versioning information to provide
more efficient deltas? Was not in the scope of delta-v working group.
- Is delta-v based on a stable webdav (i.e., is RFC2518 stable)?
Yes, and delta-v will be in a position by Nov. 2000 to make a more formal
statement about how stable it is (i.e., state that it is or explain specifically
what needs to be done).
- Throughout the document should check 'MUST' and 'must' etc. to ensure
caps are correct.
- Further prediction of how notification would be dovetailed with delta-v.
- Should have some place to refer to the other behaviors of delta-v, i.e.,
in a non-goals section of the goals document to discuss which other working
groups / technologies can be used to cover non-goals areas e.g., notification,
ACLs, etc.
- Suggestion that the protocol should de-couple the making of a baseline
and the workspace to which it relates, so that the baseline is linked to
the workspace as an explicit operation.
Response-A checked out baseline is a surrogate for the workspace itself,
without the coupling the baseline must be explicitly updated and it is too
easy to get out of sync.
Coupling also allows for significant server optimization. An open baseline
would be akin to a collection that has yet to be baselined.
- Baselines retain names of resources that are relative to the collection
of which they are a baseline.
- Must have the concept of a default workspace to be able to use baselines
-- maybe some variation on MKCOL to link it to an existing baseline?
- Checked out baselines must track the state of the arbitrary collection
to which they are bound--but unclear about what this means.
- Further discussion of implementations of delta-v servers.
- Discussion of latest changes -- core is stable, and advanced is not changing
a great deal.
- Should move goals document into delta-v working group, resubmit it to
IETF so that it is visible within delta-v. Can add dependencies in the
charter to other standards activities.
- Meeting closed at 5:39pm