Re: Workspace header

   From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>

   The thing I liked about the workspace header is that it seemed to me the
   logical resource namespace which represents the host domain,

A workspace is a collection, and therefore does define a namespace
for its members, but I'm not sure what you mean by a "logical"
resource namespace (as opposed to a physical one?) or by
"represents the host domain" (as opposed to "represents the
client domain"?).

   and the
   functional grouping of resources supporting some web application is
   orthogonal to versioning.

I don't see that a workspace has anything in particular to do with "a
functional grouping of resources supporting some web application".
A workspace is just a collection of version selectors and unversioned
resources, with a few additional properties tracking checkouts,
activities, and baselines for its members.

   By putting the workspace as a URL prefix, versioning is invading
   this logical namespace with versioning details.  This doesn't seem
   ideal. Using a header let us parameterize how to interpret the
   resource URL.

The namespace has already been "invaded" with versioning details
(e.g. versions, working resources, version histories, activities, and
baselines).

Allocating a new URL sub-tree is exactly how web servers are
commonly extended, which is why a workspace collection is compatible
with common web server extension techniques, while a Workspace header
is not.

   However, such a header does not make it clear what context
   other URLs in the request or response are evaluated in. I suggest that a
   workspace header should apply to all URLs in the request and response. That
   is, all operations are done in the context of the specified workspace.

Even URL's that explicitly refer to resources on another host?
If the host field is overridden by the Workspace header, that
means that //www.foo.com/index.html will be the same as
//www.bar.com/index.html.  That can't be right.

What about headers (like Destination) that are required to contain
an absolute URI, and therefore must contain an explicit host field.
Does the Workspace header apply to them?  If not, how do you
COPY or MOVE into a workspace?

   If this needs to be overridden for a particular resource (say the
   destination for a copy), then we can use the workspace prefix. How
   does that sound?

How is a client to determine whether a particular URL needs the
workspace prefix or not?  

Some URL's will be to resources not in a workspace (versions, working
resources, version histories, activities, baselines).  If a client has
to separately decide for each URL whether or not to add a workspace
prefix, isn't it just as easy to just always add it?

What about URL's that are embedded in dead properties of a resource?
How is a client to decide whether or not to add a workspace header (or
add a workspace prefix to override a workspace header) when it wants
to access it?

These issues are all addressed in the current protocol, but it
appears to add complexity to a client, not decrease it.

If instead, a workspace member is just a member of a collection
with its own URL, none of these issues arise.

And the original problem still remains ... since the Workspace header
is incompatible with common web server extension techniques, it will
in many cases not be implemented and therefore will be the source
of interoperability problems.

Cheers,
Geoff

Received on Wednesday, 11 October 2000 12:49:52 UTC