Re: Working collections

   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 (:-).

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).

   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.

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.

   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.

How's all this sound?

Cheers,
Geoff

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

Received on Wednesday, 22 November 2000 15:40:04 UTC