Re: Version issues

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

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:02:01 -0800
Message-ID: <004301be7ca4$6a339a00$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: David G. Durand [mailto:dgd@cs.bu.edu]
Sent: Sunday, February 28, 1999 3:24 PM
To: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
Cragun.Bruce@gw.novell.com; sridhar.iyengar@mv.unisys.com;
ckaler@microsoft.com; bradley_sergeant@intersolv.com;
ABabich@filenet.com
Subject: RE: Version issues


At 11:01 AM -0500 2/18/99, jamsden@us.ibm.com wrote:
>"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/18/99 10:15:43 AM
>2.
></jra>
>
>What is my default workspace going to do, though, when I ask for a
>versioned resource?  I believe you have indicated a preference that the
>default workspace give me either a) the checked-out revision, or b) the
>latest revision if none are checked out.  That would be okay, but why
>would I need a workspace to accomplish this?  And what if more than one
>revision is checked out?
>
><jra>
>You need a workspace because this is only one case that is a reasonable
>default. Another is checkedout, R1, and latest. That is get anything I have
>checked out, or get a revision labeled R1 for release 1, or get latest if
>the versioned resource doesn't have a revision labeled R1. This is an
>extremely simple and common case for versioning, and a workspace does it
>just fine. There might be other mechanisms that would work too, but they
>would probably end up looking a lot like workspaces.
>
>We need to think a little more about having two revisions of the same
>versioned resource checked out at the same time. Currently, this would
>require separate activities to disambiguate the working resource. Rember,
>checkouts in WebDAV aren't extracting a resource to the local file system
>where the user can specify a local file name. The resources are checked out
>on the web, are accessed using the same URL that was used before they were
>checked out (to provide uniform access), and can be accessed by many users
>at the same time subject to locks (on the working resource that is). This
>is a different paradigm, one that has different capabilities, some better,
>some less flexible.
></jra>

It occurs to me that we could allow servers to _create_ activities on the
fly when the default workspace is entering a parallel development
situation. Of course this would only be true for only for servers that
_want_ to allow such facilities for level 1 clients. The option of refusing
such checkouts is always available to any server.

This assumes that the server would be able to pass back a working resource
URI so that the different checkouts could be distinguished. I don't see any
problems with this at the moment, but they may well be lurking.

Do we really need to specify the exact behavior of which workspaces and
activities are "defaulted in" when a level 1 client does something? If we
don't, we don't constrain the server much at all -- except that it must
create an appropriate working resource _if_ it allows parallel checkout by
level 1 clients.

While it may be useful to allow this (as Chris has said) it's also
frequently useful to forbid it (as the Geoff and Brad and otherhave said).
So if we can avoid making this commitment, perhaps we should.

Since all servers won't do identical things with every protocol operation
anyway (though they will all meet some minimal semantic conditions that we
specify), perhaps different level 2 servers need not do exactly the same
thing when communicating with level 1 clients as with level 2 clients -- as
long as each one does something consistent that level 2 clients of that
server will be able to understand.

In other words, our protocol can be a subset without being so tightly
defined that level 1 operations only have one possible implementation (and
set of policies) for _all_ level 2 servers.

  -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\
http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________