RE: Proposed Simplifications to the DeltaV protocol

I love it.

I'm not going to look for fine details that may be impacted by this and need
to be caught.  Others who have been living with the spec every day will do
that.

I am fully supportive of the kind of simplification this represents and the
clarity with which it is arrived at.

This is exciting.  I can see that you are in the home stretch.

-- Dennis

AIIM DMware Technical Coordinator
AIIM DMware http://www.infonuovo.com/dmware
ODMA Support http://www.infonuovo.com/odma
------------------
Dennis E. Hamilton            tel. +1-425-793-0283
mailto:orcmid@email.com       fax. +1-425-430-8189



-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Monday, March 26, 2001 21:41
To: ietf-dav-versioning@w3.org
Subject: Proposed Simplifications to the DeltaV protocol



In Minneapolis, during the deltav design meeting and working group
session, we focused on looking for opportunities to simplify the
protocol.

The full minutes of the DeltaV meeting at Minneapolis should be
available soon, but I wanted to start a thread on issues that
directly affect the protocol.  In particular, our area director
(Ned) stated that there is only one group ahead of us for review,
which means that we need to get a new draft prepared in a couple
of weeks to keep our place in the queue.

The first proposed simplification came as a result of the Area
Director meeting the evening before.  A good part of that meeting was
occupied with internationalization issues, especially when
internationalizable strings appeared in difficult-to-internationalize
contexts (such as request URL's and headers).

This immediately raised a red flag on the Label header, which is
proposing to place internationalizable strings in exactly such a
difficult-to-internationalize context (i.e. a header).

The consensus of the room at the DeltaV working group session was that
we should remove the Label header, to avoid this internationalization
problems.  Since the Label header is an optimization (i.e. you can use
PROPFIND to determine the information), this was considered the
appropriate response to the area directors concern.  Note, the proposal
is not to remove the LABEL method, just to remove the Label header.

Any objections?

The second proposed simplification was to defer the "Variant Option".
This feature has received the least attention, and it was the
consensus of the room that it would be better to defer this feature
until it has been reviewed by a wider group (since many people that
aren't interested in versioning are interested in variants).  Note: we
started to use the term "feature" instead of the term "option".

Any objections?

The third proposed simplification was to defer the "Update Option",
with the intention of leaving it out of the protocol unless its
addition is more strongly motivated than it is currently.  In
particular, if you want to expose an older version of a VCR, you can
just check out that VCR, copy that older version into the checked-out
resource, and then check it back in.  This has the added advantage
that this does not block future work on a linear versioning server,
the way an UPDATE would (i.e. you can only check out the tip in a
linear versioning server).  It also has the advantage that it is more
compatible with the baseline and activity features, that want to
define states as merges of baselines and activities, rather than
manipulations of individual versions.

Any objections?

The fourth proposed simplification was to fold the "branch control"
feature into "core".  The idea here is that every versioning server
should expose whether or not it supports branching on checkout or
checkin, and that the additional "branch-ok" option to CHECKOUT and
CHECKIN is simple enough to require of all servers.

Any objections?

The fifth (and final) proposed simplification was to define a set of
four feature "packages", and to state that a versioning server SHOULD
support at least one of those packages.  This then allows a versioning
client to look for one of the four defined feature packages, rather
than worrying about all possible combinations of features.  Note: a
server still exposes its functionality as a set of features.

The four packages proposed are:

basic versioning:
   core
   checkout

client workspace:
   core
   working resource
   label

configuration management:
   core
   checkout
   version-history
   workspace
   merge
   label
   baseline
   activity
   version-controlled-collection

client workspace configuration management:
   core
   version-history
   working-resource
   merge
   label
   baseline
   activity
   version-controlled-collection

Any objections to these packages?

If you'd like to contribute to this thread, please do so ASAP,
so that we can meet the 2 week goal for a new internet draft.

Cheers,
Geoff

Received on Wednesday, 28 March 2001 10:09:27 UTC