W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Re (4): collection version resources

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Tue, 16 Jan 2001 09:13:09 -0500 (EST)
Message-Id: <200101161413.JAA17174@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   On Mon, Jan 15, 2001 at 08:01:11PM -0500, Geoffrey M. Clemm wrote:
   >...
   > But this does raise a good point wrt the "workspace option".  Workspaces
   > are designed so that "baselining" and "merging" would be unambiguous.
   > Which means that there is not much point implementing workspaces if
   > you are not implementing baselining or merging.
   > 
   > I'm tempted to suggest that we define the workspace option as implying
   > support for both the "baseline option" and the "merge option".  Does
   > anyone object?

   I could create a workspace, populate it, checkout a resource, modify it,
   then check it back in. Maybe hop over to the "public" VCR and update it.

   Who says that I need baselines or merging? So, I'd say "I object" until
   there appears to be a good reason for requiring one or the other.

The benefit to a client is significant.  Whenever you see "workspace" in
the OPTIONS response, you can count on a certain bundle of functionality,
so you have a common way of remembering the state of an entire workspace,
and of getting changes in one workspace reliably into another.

So the question is, is it an unreasonable burden on the server?  Although
to options are logically separable, if in practice one always implies the
other, it would be good to simplify life for clients and allow them to
count on workspaces coming with that cluster of functionality.

Just for interests sake, is there anyone out there that was planning on
supporting the "workspace" option (i.e. multiple collections which
contain different version selectors for the same set of version histories),
but which were not planning on supporting baselines and merging?

Note: I'm happy either way, but I think anything that we can to 
simplify the client's life without unreasonably constraining servers
is a good thing.

Cheers,
Geoff
Received on Tuesday, 16 January 2001 09:14:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT