Re: Version issues

jamsden@us.ibm.com
Wed, 17 Feb 1999 13:15:04 -0500


From: jamsden@us.ibm.com
To: Chris Kaler <ckaler@microsoft.com>
cc: ietf-dav-versioning@w3.org
Message-ID: <8525671B.0064B863.00@d54mta03.raleigh.ibm.com>
Date: Wed, 17 Feb 1999 13:15:04 -0500
Subject: RE: Version issues



Comments below in <jra> tags.





Chris Kaler <ckaler@microsoft.com> on 02/17/99 12:13:42 PM

To:   Jim Amsden/Raleigh/IBM
cc:
Subject:  RE: Version issues




I don't think level 1 servers want to deal with revision selection rules.
I
suspect they could be complicated.  As well, we need to understand the
semantics of parallel checkouts in the "default workspace".  The current
definition of a workspaces prohibits this and I think it is an important
requirement for level 1.

<jra>
Level 1 revision selection rules don't need to be complicated at all. There
are no activities or configurations, so the revision selection rule has
checkedout and 0 or more labels. When a resource is accessed with a simple
URL, this means, get the checked out revision if any, otherwise look for a
revision that has a matchin label. It's hard to imagine anything simpler.
</jra>

Geoff and I started talking about the Revision-Id header yesterday.  I
think
it is reasonable for a client to request version X of /foo/bar.htm.  It
seems a cumbersome requirement to have to set the revision of /foo/bar.htm
in the default workspace to be X and get /foo/bar.htm.  As well, this won't
scale at all.  Imagine one person trying to get version X and one trying to
get version Y.  We clearly need more discussion on this, but I don't yet
see
how we can eliminate a header that specifies a revision.  I do believe that
we could condense several headers into one...

<jra>
I also belive that users want to access specific revisions given the label.
If they can assign a label, they should be able to access the resource that
they assigned the label to. Recall that this capability is in the model. In
the new version I moved the method to Repository.getResource(url : String,
label : String = null) : Resource. There's also Repository.getResource(url
: String, context Workspace) : Resource to access a resource in the context
of a workspace. One reason you would want to do this is if you want to look
at an old version, or compare two revisions, and don't want to change your
workspace.

My issue isn't that I didn't want access by labels, only that access when
labels aren't specified should use Workspaces to resolve the URL.
</jra>

I, personally, think that RSR are interesting but probably too complicated
for level 1 servers.  We could say that the SETDEFAULT method is a
"utility"
method that modifies the workspace to use the specified revision of the
specified resource.  This allows us to still describe level 1 functionality
in the context of level 2 workspaces.  And for level 2, it provides a handy
service for augmenting an RSR without having to pull it, modify it, and put
it.

<jra>
Again, I don't think revision selection rules are complicate at all,
especially for level 1 which doesn't have activities, merging, or
configurations. The complexity results from introducing multiple revisions.
Leaving workspaces out of level 1 will just move the complexity to the
client or user who have to remember lots of labels on a resource by
resource basis. This makes the server simpler, but not WebDAV.

I stress again, what would anyone want to do with versioning level 1 that
workspaces wouldn't support? What would workspaces include that would be
considered too much for level 1? We need specific scenarios that address
these issues. As you know, I am also keen to keep things simple. Its just I
want the simplicity for the users and clients, not necessarily just for the
server.
</jra>

Thoughts?

Chris

-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Tuesday, February 16, 1999 12:56 PM
To: Chris Kaler
Subject: RE: Version issues




But if we keep the Revision-Id header and a SETDEFAULT method, this will
conflict with level using a default workspace. I suggest we effectively use
default workspaces for level 1. This doesn't mean servers have to implement
them, only do something that makes them look like they work. Clients should
be able to use level 1 services without being aware of workspaces. If
activities and configurations are not in level 1, then the workspace only
has to consider revision selection rules that include checkedout, latest,
and revision labels. This should be pretty simple.






Chris Kaler <ckaler@microsoft.com> on 02/16/99 03:21:30 PM

To:   Jim Amsden/Raleigh/IBM, ietf-dav-versioning@w3.org
cc:
Subject:  RE: Version issues





[CK] Comments below...

A few issues came up at our last versioning working group meeting:

1. DAV versioning level 1 will still need to be a way of resolving access
to versioned resources given just a URL (and not a label). If workspaces
aren't supported, level 1 servers will have to provide some other way to
resolve URLs to specific revisions, perhaps a default revision for each
versioned resource. For level 2 servers that do support workspaces, this
would result in two, potentially conflicting ways of performing URL
mapping. This is a strong argument for including workspaces in level 1.
What would anyone want to do with versioning level 1 that workspaces
wouldn't support? What would workspaces include that would be considered
too much for level 1? If there are no compelling answers to these
questions, we should include workspaces in level 1, including the default
workspace.

[CK] I suggest we keep the Revision-Id header and the SETDEFAULT method.

2. Deleting a resource must explicitly state that the resource is removed
from its parent collection; that is, the collection with which the resource
is an internal member. Versioning complicates delete semantics. There are
three things we might want to delete: an unversioned or working resource, a
revision (and all its descendents?) of a versioned resource, a versioned
resource and all its revision history. This must be done in the context of
versioned and unversioned collections that contain the resource, or
versioned resource as an internal member. The preferred way to do this
would be to have add and remove methods on collections to create and delete
resources as its the collection that controls the namespace. Unfortunately,
DAV doesn't have those semantics, so we will have to find a work-around for
versioning.

[CK] I expect deleting a working resource to be the same as UNCHECKOUT.
[CK] Deleting a versioned resource is up to the store.  Some stores might
[CK] just delete it.  Some might create an "delete" version.  I don't think
[CK] we want to push a specific model on people.  Especially since the
[CK] DELETE method is about a resource and in no way describes the
[CK] underlying repository actions.

Actually, the current WebDAV spec is a little confusing about collections
and their members. The current spec indicates collections contain URLs, not
resources. But, there is the notion of internal members and referential
members, and deleting a collection deletes all its internal members. So the
collection behaves like it contains resources, not URLs. This issue will
likely get more confusing when we add versioned resources, versioned
collections, and multiple revisions.

[CK]Your right -- some clarification here would be could.

3. It is not possible to automatically create workspaces or activities for
either non-versioning clients, or versioning clients that don't specify
them. Default workspaces and/or activities must be used. Creating a new
workspace or activity on each request could cause resources that were
manipulated in the previous request to disappear.

[CK] If we say this is what "logically" happens on a Level 1 server then
[CK] OK.  But if the server must in fact do this, then I think the cost
[CK] is too high since Level 1 clients don't care about this information.