Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:08:57 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:08:57 -0800
Message-ID: <005501be7ca5$625c0b40$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Tuesday, March 16, 1999 4:22 AM
To: ckaler@exchange.microsoft.com
Cc: Bradley.Sergeant@merant.com; BCragun.ORM2-1.OREM2@gw.novell.com;
jamsden@us.ibm.com; dgd@cs.bu.edu; ejw@ics.uci.edu
Subject: Re: Version issues



I totally agree with the need to keep the concepts of configuration
and workspace cleanly separated.  Currently, I have a restricted form
of workspaces as a level-1 protocol element (i.e. as a checkout-token
and as the default-workspace), but configurations do not appear until
level-2.

Cheers,
Geoff

   From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
   Cc: Bradley.Sergeant@merant.com, BCragun.ORM2-1.OREM2@GW.Novell.com,
	   jamsden@us.ibm.com, dgd@cs.bu.edu, ejw@ics.uci.edu
   Date: Tue, 16 Mar 1999 00:05:33 -0800
   X-Mailer: Internet Mail Service (5.5.2232.9)
   Content-Type: text
   Content-Length: 2593

   So long as its possible.  For example, I don't think we have cleanly
   separate a configuration from a workspace.  I fear that if we don't
   keep this everpresent, we will end of with tightly coupled concepts.

   Chris

   -----Original Message-----
   From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   Sent: Monday, March 15, 1999 9:34 PM
   To: Chris Kaler (Exchange)
   Cc: Bradley.Sergeant@merant.com; BCragun.ORM2-1.OREM2@GW.Novell.com;
   jamsden@us.ibm.com; dgd@cs.bu.edu; ejw@ics.uci.edu
   Subject: Re: Version issues


   One possibility is that although multiple levels of versioning models
   are almost inevitable, by the time we have abstracted out the versioning
   models to a protocol, that these distinctions may no longer be visible.

   So we may want to pospone discussions about the protocol levels for
   when we are discussing the protocol rather than the versioning model.

   Cheers,
   Geoff

      From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
      Cc: BCragun.ORM2-1.OREM2@GW.Novell.com, jamsden@us.ibm.com,
   dgd@cs.bu.edu,
	      ejw@ics.uci.edu
      Date: Mon, 15 Mar 1999 09:50:14 -0800
      X-Mailer: Internet Mail Service (5.5.2232.9)
      Content-Type: text
      Content-Length: 1363
      X-Lines: 28


      I still vote for two levels.  I believe there is a minimal level that
we
      can get people to agree on.  I also believe there is a maximal level
that
      we can get people to agree on.  Finding an intermediate level that is
      right for more than a couple of vendors seems unlikely to me, and I'd
   hate
      to spend too much time trying to find one.
      [CK] I'm not wild about > 2 levels, but this approach will result in
	   limited level 2 support.

      In particular, I find it much more likely that if we carefully design
the
      maximal features to be orthogonal, then vendors can pick the subset of
      those features that get them to where they need to be, while still
      maintaining
      a reasonable degree of interoperability based on the shared minimal
   feature
      set.
      [CK] I believe that if we do this, then a "de facto" level 1.5 will
	   emerge.  Better that we define it up front?

      Another way of phrasing it is that I see the definition of these
      intermediate
      levels to be a prime candidate for the more informal process that JimA
      has described for standard properties.
      [CK] I believe we will do a disservice to versioning and will result
	   in non-interoperable servers.  Clients will have to use OPTIONS
	   to determine if the server supports there level 1+ features and
	   in the end, clients will become too complex (because of the
	   degrees of freedom) or interoperable.