- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 16 Jan 2001 09:13:09 -0500 (EST)
- 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 UTC