Re: 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,

I shall eagery await them.

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

Great.

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

I don't see what the problem is here.  We have declared the character
encoding for the label header (UTF-8) to be inclusive of multiple character
representations.  We are not faced with national language issues, since
clients will not be rendering the labels in different languages -- if it is
labelled 'release 1.0' that will not be translated into the equivalent
French, German, or whatever.  So as I understand it we need only address
the encoding scheme; and this has been done.
Are you suggesting that that language should also be retained with the
label?

> The consensus of the room at the DeltaV working group
> session was that we should remove the Label header, to
> avoid this internationalization problems.

I need to see the explaination of the problem.

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

I think this is unnecessary.
Unless servers are required to retain the language information declared in
the body of the LABEL it seems pointless.
In addition, I agree with John that this is a significant optimization
(even if there were a label report) that was added to the document early
on, did not cause any objections, and we should strive to keep it in.

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

No.  Good riddance.

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

I strongly object to this one.  If you have any respect for version history
then using UPDATE to expose the older version of a vcr is *significantly*
different to extending the tip with an equivalent version.  Disallowing
UPDATE will cause significant growth in the number of versions for those
systems that routinely roll time back-and-forth for a set of resources.

Greg's suggestion of using version url's is unsatisfactory since it does
not allow for documents that contain links (based on vcr names).

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

That's fine.

> 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

How do you create a working resource if you don't have checkout?

> 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

Ditto -- for checkout.

> Any objections to these packages?

Since they are only SHOULD's it would be difficult to object <g>.
Are they useful ... ?

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

Done.

Tim

Received on Wednesday, 28 March 2001 13:33:45 UTC