Re: Version issues
Dylan Barrell (dbarrell@opentext.com)
Sun, 9 May 1999 23:52:47 +0200
Message-ID: <01BE9B1B.4E7957B0.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: "ietf-dav-versioning@w3.org" <ietf-dav-versioning@w3.org>
Date: Sun, 9 May 1999 23:52:47 +0200
Subject: RE: Version issues
> Your points about the benefits of several versioning levels in various
> aspects of versioning support are valid. These benefits must be
> weighed against the cost of the combinatorial explosion in complexity
> that this induces in the specification and in an interoperable client.
> Two versioning levels is actually three, since "no versioning support"
> is one of the alternatives. This means that there are eight
> combinations that the specification and vendors must be concerned with:
>
> level-0 client -- level-1 server
> level-0 client -- level-2 server
> level-1 client -- level-0 server
> level-1 client -- level-1 server
> level-1 client -- level-2 server
> level-2 client -- level-0 server
> level-2 client -- level-1 server
> level-2 client -- level-2 server
Purely combinatorially, I agree, but actually a level 0 client will only
receive level 0 responses from a server regardless of the server's support
level, as it will only send level 0 requests. The same goes for every other
level.
>
> I encourage you to enumerate all the combinations resulting from a
particular
> set of levels and variants you propose, and an effective way for the
> protocol writers, server vendors, and client vendors, to deal with them.
I want 2 levels
level 0 - only versioning and nothing else - no workspaces, change sets or
configurations
level 1 - whatever else you want to throw-in
>
> It is also important to note that two levels of versioning support
actually
> provides a significant degree of flexibility to a vendor that is
providing
> both a client and a server. In particular, if the vendor provides at
least
> level-1 support in their server, then they can add any subset of level-2
> support to their server, and design their client around that subset. The
> following interoperability will then be guaranteed:
Exactly, I am just arguing about what should go into level 0.
>
> vendor client -- vendor server
> level-1 client -- vendor server
> vendor client -- level-2 server
>
> In order to maximize the choices available to such a vendor, the design
team
> is working hard to ensure that level-2 functionality is divided into
> logical pieces of functionality that are as orthogonal to each other as
> possible, so that a variety of vendor choices between level-1 and level-2
> are feasible.
I don' see how this could possibly make sense - unless level 2 (I have
referred to this as level 1) requests can all legally send an unsupported
response and the server still be considered compliant.
Cheers
Dylan