Re: workspace header

    When a Workspace header is included in a request, the internal
    members of that workspace are treated by that request as if they were
    internal members of "/".

   <tim> yes, '...by that request...' no mention of the response <g>

Well, since the request generates the response, I'd think that it
would necessarily follow (:-), but I'll add some words that explicitly
state this.

   This means that all URL's generated in the responses must act that
   way as well (i.e. act as if the way to get to members of the collection
   is by going through "/").

   <tim> This would be the natural assumption, but what about the URLs to,
   say, working resources that cannot be expressed relative to a workspace.

This is certainly an issue with a Workspace header.  One approach is
to put those workspaces on a different (possibly virtual) host.
Another approach is to put a binding to those resources in every
workspace (probably the approach our implementation will use).

As a side note, if you are supporting workspaces, you commonly
will be checking out the version selectors, not versions, so
working resources would not be an issue.

<tim2>
I don't understand what you mean by 'putting abinding to those resources in
every workspace'.
In particular, say you do a property report against a version selector, to
get its target value and 'follow' it's target to find the URL of the
history resource.  Would you poof-up mappings for these values that are
relative to the workspace header?  Presumably there is little choice.

   <tim> In any case, I think it would be polite if the server mentioned
the
   workspace URL it was using in its response.

That's fine with me.  I'll add it in, since I don't think anyone will
object (we can always take it back out, if someone comes up with a
good objection).

Cheers,
Geoff

Received on Friday, 6 October 2000 06:05:57 UTC