Re: target selector again
jamsden@us.ibm.com
Tue, 5 Oct 1999 17:11:21 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256801.00747E4B.00@d54mta03.raleigh.ibm.com>
Date: Tue, 5 Oct 1999 17:11:21 -0400
Subject: Re: target selector again
I agree with everything Geoff say below.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 10/05/99 02:54:36 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: target selector again
From: jamsden@us.ibm.com
Maybe the Target-Selector should be a RSR, i.e., a list of revision
selectors.
<gmc/> I'd be strongly against allowing that. A Target-Selector is
just a header, while an RSR contains an arbitrarily large amount of
text. Putting an RSR in a header is just asking for errors due to
truncation by proxies and such.
<gmc/> Since you have to have a workspace (not just an RSR) to check out
a resource (and to reference the checked out resource), putting
RSR's in a Target-Selector would have limited utility in any case.
<gmc/> On the other hand, allowing the Target-Selector to be a
single (non-nested) RSR element is fine with me (as long as there
aren't some hidden gotcha's in storing XML in a header).
We also talked about a "path of revision selectors" to
specify the revision selector for each element in the URL path. All
this was to avoid mangling the URL with things like
http://host:8080/foo@2/bat@33/index.htm@25.
<gmc/> The "path of revision selectors" is just a constrained form of
an RSR, with all of the disadvantages mentioned above and fewer of the
benefits (:-).
We may also want to associate a context with a user that could include
his workspace, current activitiy, etc. This is effectively what "local
mode" does.
<gmc/> Since a workspace is normally used by at most one client at any
given time, the workspace resource is a logical place to store any
"context" information (i.e. as properties on the workspace).
What is "local mode"?
Cheers,
Geoff