Mail never hit list

I was double checking my records and my response to the workspaces never
made it from the list-serv to the list.

Here is the body of the message I sent:
---------------------------------------

>    The concept of 'client' and 'server' workspace do not make sense to
>    me unless you are trying to use it to mean a descriptive term to
>    describe where version control is being done.  What is referred to
>    as 'server-workspace' in the draft is a workspace that exists on
>    the server that is client accessible.
>
> Yes, the option names (such as "client-workspace" and
> "server-workspace") are descriptive terms.  For parallel development
> of several resources, you will always need something like a
> "workspace", i.e. a place where those resources live with appropriate
> relative names.  In the "client-workspace" option, the workspace is on
> the client (and therefore have no explicit resource for them on the
> server), while in the "server-workspace" option, the workspace is on
> the server (and therefore has an explicit resource on the server, the
> "workspace resource").

In the context of a DeltaV specification, I would feel more comfortable with
the following.

Can we transition from using the terms "client-workspace" and
"server-workspace" to "working resource" and "workspace" which more
appropriately capture the functional meaning of the contents in the
specification.

The working resource is beneficial for implementations of workspaces on the
client.  As a server-side implementation, it is beneficial to have working
resources created in the confines of a workspaces.  This has no influence on
how a client manages its own workspaces but rather provides for server-side
management of the working resources.  Two reasons while this is beneficial
from a server perspective:

1) Merging
We have found that it is easier to handle conflict resolution within the
confines of the workspace.

2) Management
A successful WebDAV/DeltaV server will have a large number of working
resources created and managed.  Each working resource will have a reference
on the server and overhead for each will depend on the implementation.  Over
time, the number of dangling working resources increases due to failed
clients, communication problems, etc.  A workspace provides a container for
segregating the working resources so they can be managed.  Once tasks have
been completed, the workspace can be deleted and all working resources (and
conceivably all residuals from merging, etc) are deleted as well.  We've
identified that this is easier to do within a particular working confine
(such as a workspace) that on the main branch.


>    > > And the bit about a workspace as a precondition: sections 5.5 -
>    > > 5.7 actually work without needing "workspaces." It is a bit
>    > > confusing because they are placed into the "workspace" section,
>    > > when they really just mean "editing resources on the server
>    > > [with or without a workspace]." IMO, they should move to a
>    > > different section, or somehow be clarified that they do not
>    > > require a "workspace" to operate.
>
>    > Yeah, that was just a somewhat forced attempt to cut down on the
>    > number of options.  It seemed like the only people asking for "in
>    > place checkout" were those who were planning on implementing
>    > workspaces, so I bundled "in place checkout/checkin" with the
>    > workspace option.  Another way to look at it is that a server can
>    > support the "server-workspace" option, but fail a user's attempt
>    > to create new workspaces with MKWORKSPACE.  I'd probably prefer
>    > this over splitting this into two separate options (although I
>    > agree that they are logically separable).
>
>    I need to think about this one some more.  If the
>    version-controlled resource (VCR) is in a workspace, doesn't the
>    workspace need to exist as a precondition regardless of whether or
>    not a separate URL for the workspace can be discriminated?
>
> I think it is clear my "simplification" is actually confusing things,
> so I'll break these would into two separate options as Greg suggests,
> namely one option which lets you do CHECKOUT/CHECKIN/UNCHECKOUT of
> a version-controlled resource, and another option which lets you create
> separate workspaces on the server (the latter is the "server-workspace"
> option).

I see you moved this to a different section.  I was just shooting for
completeness; if a VCR is in a workspace, workspace existence is a
precondition even if guaranteed.  Enough said, the point is mute.

	Thanks, I enjoy working with you all,

	Mark

Received on Friday, 12 January 2001 11:22:19 UTC