Re: Working collections

Okay... I've had plenty of time to ponder the implications. Finally time to
discuss :-)

On Wed, Nov 22, 2000 at 03:39:25PM -0500, Geoffrey M. Clemm wrote:
> 
>    From: Greg Stein <gstein@lyra.org>
> 
>    At another point, I had stated that I didn't want to create a "tree"
>    underneath the working collection, and how I was thinking of accomplishing
>    that. Pretty simple: return 404 for resources under the working collection.
>    Only a DELETE would be allowed for immediate members of a working
>    collection.
> 
> OK, it looks like I haven't convinced you that you really want to
> create a logical tree on the server (aka workspace) for each user (:-).

Yup. As I pointed out elsewhere, it is dramatically easier for us to create
working resources that reference a particular version resource, than it is
to create a workspace that can reference arbitrary resource versions. And
our "public view" just references the "head", so we don't need to track
version data... just the correspondence between hierarchies.

> So if we are plunging into dreaded choice C (:-), let's see if
> we can make it as close to A or B as we can.  Since you don't want
> to create a tree of version selectors, that eliminates choice B.
> Choice A (analagous to versions) says that version controlled members
> of the collection are version histories.  This actually looks pretty
> good, since you can't slash through version histories, they don't
> create a tree of version selectors, but you could delete them from
> the working collection (you can't delete them from the version history
> namespace, but there's nothing to stop you from deleting them from
> the working collection namespace).

Agreed on all counts.

>    If you do a PUT or a MKCOL to a member of a working collection, then a new
>    working resource will be created, and that URL will be returned in the 201
>    (Created) response's Location: header. This allows me to avoid nesting the
>    working resources by effectively redirecting to the created working
>    resource.
> 
> I have what I believe is a simpler proposal.  You can create as many
> non-versioned resources as you want in a working collection.  When
> you checkin a working collection, all non-versioned resources are put
> under version control, and are replaced by their (newly created)
> version history resource.  The "put under version control" works
> leafs up, so you can create trees of non-versioned resources inside
> of a working collection before checking it in.  The working collection
> is deleted on checkin, as a working resource is, but all your work is
> saved in the standard form of versions and version histories.

Agreed.

Note that, in my particular case, I can avoid the "replaced by..." part
since the creation of version histories, the checkin of the working
collection, and the final deletion of the working collection are completely
atomic. e.g. the replaced resource gets deleted, so there isn't a need to
model that semantic (in my case).

> If you want to subsequently checkout any of those newly versioned
> resources, you would just CHECKOUT the desired version, and get a
> working resource just as usual.

Right... they're just normal version resources.

>    I'm not sure how a PROPFIND on a working collection would operate, if it had
>    a non-zero depth. I might refuse them to avoid the implication that other
>    resources exist under the working collection.
> 
> If the members of a working collection are either version histories or
> non-version-controlled resources, PROPFIND behavior would be well defined.

Right!

> How's all this sound?

Sounds terrific, and it shouldn't be too hard to model code-wise.

>...
> p.s. (I still think you should just create a workspace
> on the server for each client :-).

You just never quit, do you? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Sunday, 3 December 2000 02:53:12 UTC