Next message: Geoffrey M. Clemm: "DAV:revision-resourcetype"
Date: Thu, 20 Jan 2000 22:23:00 -0500
Message-Id: <10001210323.AA26116@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Fw: Some DeltaV questions
Great questions, Neil!
From: Neil Weber
While reading over the latest draft of the spec, I had the following
questions.
The WebDAV spec talks about different classes of WebDAV compliance a
resource may support. The DeltaV spec defines three levels of versioning
support but does not explicitly state whether these levels apply to the
WebDAV server or to each resource. The specification of changes to the
OPTIONS method indicates the level applies to the server. Do the levels
apply to the server, the resource, or maybe to the repository?
In general, the OPTIONS method is applied to a resource, so the
versioning levels are on a resource by resource basis. In fact,
it is likely that all versioned resources in a particular repository,
or perhaps, on a particular server, will have the same level of
versioning support, but since the concept of a "server" or a "repository"
is not a defined HTTP entity (except may for the 'OPTIONS *' request),
a client would discover this information on a resource-by-resource basis.
The DeltaV spec does not state the WebDAV compliance class of each new type
of resource. Each new DeltaV resource type must obviously comply with
WebDAV class 1 because they have properties, but should they also be class 2
compliant or does it not matter? In particular, I'm thinking about a
working resource. If each resource may have a different DeltaV level, what
are the required levels for each new resource type?
There is no requirement in the versioning protocol that WebDAV class 2
be supported. It is likely that servers will support locking on versioned
resources, in order to provide interoperability with versioning-unaware
clients, but that is up to the server. A client can use OPTIONS to discover
if locking is supported.
Are the revisions listed in a Versioned Resource's DAV:revisions property in
any particular order?
Not currently. We could make them ordered (using the ordered
collection functionality), but whatever ordering we picked will in
general not correspond to a particular server's order, and therefore
might be expensive for that server to maintain. I'd say, just let
the client do it.
On the other hand, it would make sense to identify the "initial-revision"
of a versioned resource, so that a client can iterate from the initial
revision in some sensible behavior.
So I vote, add a DAV:initial-revision property to versioned resources.
Anyone against?
If they aren't, how does a client determine which is
the latest revision? It could look at the checkin dates, but that would be
very expensive.
They could pick a workspace with DAV:latest as the revision selection
rule. But in general, the "latest revision" is not very meaningful
in the context of parallel development. What is more interesting
is "latest in a particular activity". This is achieved by selecting
that activity in the revision selection rule of your workspace.
What is the behavior of a DELETE on a checked out resource?
The DELETE is actually an operation on the collection containing the
checked out resource. The working resource is still available as long
as there is any way to get access to the versioned resource that is
checked out (then you just pass in the appropriate workspace header
to get access to the working resource).
On an activity? Configuration? Repository?
Like other resources, if the delete removes the last binding to the
resource, the server is free to garbage collect whatever physical
resources are used to maintain the state. In practice, there probably
will be non-WebDAV references to those resources, so the delete merely
removes a WebDAV binding to the resource, not the resource itself.
Working resource?
A working resource is a checked out resource (see above).
Should a MOVE on a working resource fail?
Depends on which collection contains the resource you are applying the
MOVE to. If it is a modifiable collection, then the move is applied
to the member of the collection (which commonly will be the versioned
resource, not the working resource), and the working resource
effectively moves along with the versioned resource.
On a checked out resource?
A checked out resource is a working resource (see above).
Revision? Activity? Repository?
Some servers may fail attempts to move these objects (so that it doesn't
have to recompute properties that refer to them), but that's up to the
server implementor. On the other hand, the client would probably like
to take advantage of the stability of at least the server defined revision
names, so perhaps we should require that MOVE fails when applied to the
server defined URL for a revision.
When a CHECKOUT creates a working resource, what should be the initial value
of DAV:checkin-policy? Should it be the default value of DAV:new-revision
or maybe a copy of the revision's DAV:auto-version property?
Currently, the default value is defined to be DAV:new-revision.
I think that's better than emulating the DAV:auto-version property.
Anyone feel otherwise?
Is the order that post-conditions are listed in significant? I ask this
because the second post-condition of CHECKIN (about apply the property
updates) would have an effect on the first post-condition.
Good point.
I propose to fix this by combining these two into a single post-condition
that says the result is a copy modified by the updates.
How can a client record the author or change comment of a revision?
Obviously dead properties can be used, but would it be worthwhile to
standardize a property names?
That is what DAV:author and DAV:comment are for. Or did I misunderstand
the question?
The term "Line of Descent" is defined but not used anywhere else in the
document. What is the significance of this term for DeltaV?
It is currently used in the definition of a conflict report, and in a
restriction on the revisions in an activity. It's not a critical term,
but it is occasionally useful.
Isn't another post-condition of CHECKIN, that the DAV:last-modified property
is updated to the current date and time? Or is there no need to mention
this level of detail?
I think that follows from the definition of DAV:last-modified, so I
don't think it needs to be repeated here.
Which properties introduced by WebDAV are writable and which are read only?
All properties are writable unless explicitly defined in the spec as being
readonly.
Consider this scenario
A client does a GET X
There is no workspace header, so the default workspace is used.
The default workspace has an rsr of label GA.
Revision 1.4 of X, last modified on 1/5/00, has label GA.
Revision 1.4 of X is sent to the client along with a Last Modified
header of 1/5/00.
The GA label is moved to revision 1.3 of X to avoid a problem with
revision 1.4.
The same client does another GET X, this time with an If-Modified-Since
header of 1/5/00.
The default workspace is used again.
Now revision 1.3 of X, last modified on 1/1/00, has label GA.
A 304 "Not Modified" is returned.
So, the client will display the wrong revision of X. Or, is there something
I've missed?
This is a good point.
If-Modified-Since cannot be reliably used with versioned resources
(for the reasons you describe above).
This probably should be highlighted somewhere
The server could return a different etag for each revision,
but a resource may not have an etag. Nor does the DeltaV specification
state that the etag should differ for each revision.
I believe that the definition of etag requires that it be different
for each different state of a resource, so applying this to versioned
resources implies that all revisions that differ must return different
etag values.
Cheers,
Geoff