RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

At 12:10 2/2/99 -0800, Chris Kaler wrote:
>[CK] The point of using "giberish" in the draft is to reinforce
>     that the server determines the value.  A server could make it
>     giberish or something else.  One limitation we have is the
>     strong reluctance in IETF to "munge" URLs.

Is there a document describing what the IETF folks mean when they
describe "mungeing" URLs?  The image that comes to mind is tacking
on decorations like # and ? with information after them, or creating
extra namespaces like the ones for configurations and checked-out
files.

I see a URI as a three-dimensional phenomenon-- taking us through
a space dimensioned by machine/protocol/port combinations (each unique
one defining a plane), directories (the vertical aspect of the plane,
if you consider the directory hierarchy unfolded completely) and files 
in directories (the horizontal aspect of the plane, with files as
chains following folders).  

Versioning adds a new dimension.  I see the headers as allowing us to add 
that new dimension (version number, etc.) to the URI, rather than trying 
to map the fourth dimension into other parts of the plane (which is
what a temporary file created for checkin/checkout purposes is).  
Since headers such as Revision-Id are already in use to provide that 
fourth dimension for accessing concrete versions, using them to 
access temporaries seems to me the least work to implement and the most 
consistent.  Of course, having eight different things happen depending on 
three different headers you might or might not send could be precisely what 
the IETF considers URL mungeing.

>[CK] I think it is important to remember that these are protocol-level
>     resources.  I would assume that the UI on top of the protocol hides
>     all this.  For example, you "checkout" and "checkin" based on the
>     resource name you desire.

For sufficiently general values of "based on", yes. :-)  The current
document gives the example of CHECKIN /tmp/VRJHJWE3493409 HTTP/1.1,
which makes no reference to the resource name involved.

As long as the user thinks they're checking in to the usual location,
it doesn't really matter, but things in the underlying implementation
have a way of percolating up to the user's view of the world.  It
also makes life easier for watching the requests as a programmer
or administrator.

>                                The working copy resource is part of the
>     implementation and isn't visible to the user.  As well, there is
>     always the DAV:displayname property.

Perhaps checked-out temporaries should have a property that
points at their original document and version?  Or should the
lineage report suffice for that purpose?

[re:  my idea for CHECKOUT/CHECKIN/UNCHECKOUT]

>[CK] I don't think so.  The idea is that a CHECKOUT creates a working copy.
>     Technically this is not part of the revision graph for the resource.
>     It must be mutable because clients need to be able to make multiple
>     changes.  You can't version it because it isn't part of the version
>     graph.  It is just a scratch space where PUTs and PROPPATCHs can be
>     performed until the resource is ready.  CHECKIN then assigns a revision
>     id and makes it part of the graph.  Working copies don't have revision
>     ids.  Also, UNCHECKOUT cancels a CHECKOUT.  You can't issue UNCHECKOUT
>     once you've issued a CHECKIN.  The draft should be clearer on this
>     point.

Sorry; I should've been clearer.  (It does seem pretty obvious that 
you can't UNCHECKOUT once you've done a CHECKIN; I probably just
flubbed the language.)  I meant to suggest:

1.  "CHECKOUT uri" returns 200 OK and gives you a token instead of
    201 Created and an URL.
2.  "PUT uri" and "PROPPATCH uri" with the token provided in the request
    header allow you to meddle with the working copy at uri to your 
    heart's content.  If uri isn't locked, there could conceivably
    be multiple such working copies, each accessed with different tokens.
3a. "CHECKIN uri" with the token would check in the working copy with
    a proper revision ID, release any locks you have on the original uri
    (unless you explicitly request to keep the locks), and lose all
    record of the token; alternatively,
3b. "UNCHECKOUT uri" with the token would remove the working copy, all
    record of its token, and any locks you had on it.

The token could be passed as a Revision-Id of some particular sort, if
you treat working copies as mutable revisions, or in some other fashion.

>The same thing applies to configurations:  do they need to exist
>in special areas?  [...]

>[CK] The idea here was to put them in a unified place so that standard
>     DAV discovery mechanisms can be used.  Otherwise we need to add
>     new methods to discover the configurations.

They could always exist as normal residents of the namespace who
happen to have a DAV:resourcetype of DAV:configuration-- they could
sit there next to collections and ordinary files.  (Once references
are implemented, I don't see it as that much more trouble to do
other special entities.)

[An aside:  we've been doing a lot of hammering on a very similar
notion over here at Glyphica for our next product, which is intended
to be WebDAV-compliant, and the "configurations" from the versioning
draft sound a lot like the "projects" we've been debating over here.
After much hammer-and-tongs haranguing about the natures of projects, 
we settled on the notion that a project would have a lot of links but 
could own entities in its own right, in order to simplify matters
of hierarchy.  I'm trying to figure out if a project is likely to 
*be* a configuration or *use* a configuration.  The example in the
versioning goals isn't much different from labeling a source tree,
which you can do with a BRANCH operation in this specification.
Were there any other examples that you folks used in coming up with
what a configuration should be able to do?]

From an object-oriented point of view, I'm thinking of configurations
as a subclass of collections with some added functionality.  Both
accept PROPFIND with a Depth header, both need to manage a bunch
of other entities when you use COPY and DELETE and MOVE.  A
Configuration-Id URI would tell the system where the configuration is,
so there doesn't need to be any central lookup location; putting
a collection that is not a configuration in the Configuration-Id
header should generate an error.

>[CK] Configurations are very similar, but also very different.  A
>     configuration collection can be referenced in the Configuration-Id
>     header.  That is not true of all MKREF collections.  As well, changes
>     to the resources in the context of a configuration are automatically
>     represented inside the configuration collection.  That is, if I
>     rename foo.htm to bar.htm using MOVE in the /c/1 configuration, then
>     inside /c/1 there will be a reference to bar.htm.

I'm not sure I got that.  Do you mean that 

MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /c/1/foo.htm
Destination: /c/1/bar.htm

works as expected, (/c/1/bar.htm is a reference to /potzrebie/foo.htm,
just like in a collection), or

MKREF /c/1/foo.htm
Ref-Target:  /potzrebie/foo.htm

MOVE /potzrebie/foo.htm
Destination:  /potzrebie/bar.htm

will update /c/1/foo.htm to point to /potzrebie/bar.htm?

>Should configurations be able to contain other configurations, or
>simply references to them?  I can easily see that a configuration's
>user might wish to partition it when it gets large and cluttered.

>[CK] This is a really interesting question.  Conceptually, why not?
>     However, that is really hard to represent in the resources.

More than a collection is?  I may be missing something here...

>                                                                  As
>     well, some of the semantics start to get really messy.  What does
>     it mean to have nested configurations?  What does it mean for a
>     resource to be "in" nested configurations.  We opted to say that a
>     configuration can be derived from another, but there isn't a notion 
>     of containment.

If a configuration is a collection with special attributes for how it
interacts with the configurations it derives from and that derive from
it, and containment is handled like any collection, does that open
any cans of worms?

>I'm thinking of software development solutions:  a configuration might
>represent a project, with subconfigurations containing subprojects.
>You'd want automatic inheritance from the core project so any time
>someone else added a file to the configuration, you got a reference
>to it. [...]

>[CK] Another way to think of this is that the collections in the
>     namespace represent the project and sub-project relationships
>     and that configurations represent various "releases" of those
>     projects.  In this way the "V2" configuration can be derived
>     from the "V1" configuration.

So you have:

1.  A bunch of actual files in a namespace, representing the source tree.
2.  A number of configurations, each representing a separate release of the
    code, with links into multiple levels of the source tree.
3.  Many more configurations, each depending on the release configurations,
    representing developer workspaces.

The developer would then use the actual URIs from (1) for dealing with
the files and personal (3) workspace as a header to to select the 
appropriate versions from (1), and seldom (if ever) actually see the 
contents of (3)?  (Logging in to a workspace becomes interesting:
how to choose from among a bunch of configurations?  

Thus, most WebDAV operations would not occur on configurations
directly.  All the PUTs and GETs and PROPPATCHes and LOCKs and 
UNLOCKs would happen using the URIs from (1) and the configuration
ID from (3).  The configuration would occasionally be added to
through MKREF and removed from via DELETE, but all of this would
happen behind the scenes.

This makes a big difference in my visualization of configurations.  The
impression I got from the document was that a user might want to create a
configuration in their home directory on a server and use that as their
local copy of the data in the source tree, that configurations would be
something that you navigated into just like a normal directory tree.

What I'm seeing now is something more like a lock token with a lot more
state packed into it.  A user would "log in" to a configuration and
begin sending the configuration-id header along with almost all
requests to the server.  This would provide a context for their
particular view of the source tree.

Could a user ever wind up being "logged in" to multiple configurations?

[re: BRANCH]

>[CK] This is something I should have made clearer.  Both are valid.
>     The VER:... notion is used to refer to a specific revision via
>     a URI.  You can also specify the URL and the Revision-Id header.
>     Chalk this up to a bad example.

Hopefully, the VER:... URI functionality will be optional?  Should there
be a way to discover this functionality through OPTIONS?

>>Regarding SETDEFAULT:  why is it specified as sending an XML body?

>[CK] The idea was to allow the user to specify additional information
>     as well as allow the DAV:none to cancel.  We could do this all 
>     through headers, but XML seemed appropriate.

What other information would go in with SETDEFAULT?  For that matter,
is SETDEFAULT really doing anything you couldn't with PROPPATCH?
If I'd read that SETDEFAULT functionality was to be implemented with
a live property named DAV:defualtversion, I wouldn't have blinked...

***

Another question that comes to mind:  why are there properties using
comma-separated lists (such as DAV:revisionlabel, DAV:mergedfrom, ...) 
instead of an XML representation of such a list?  I would think
	<D:revisionlabel>
	  <D:label>Beta test</D:label>
	  <D:label>Release</D:label>
	</D:revisionlabel>
would be more in keeping with the standard.

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%

Received on Friday, 5 February 1999 18:24:58 UTC