Re: workspace header

   From: Tim_Ellison@uk.ibm.com

   <tim> ... 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).

   <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.


Suppose your working resources are named "/repo/wr/..."
and your workspace is named "/ws/tim_def"

Then the server responsible for "/ws/tim_def" could automatically
create a binding named "repo" (to the "/repo" collection) in
"/ws/tim_def".  This would mean that URL's like /repo/wr/... would
work both with and without a Workspace header.

Of course, if you happen to already have a real member of /ws/tim_def
that is named "repo", you are out of luck.

Cheers,
Geoff

Received on Friday, 6 October 2000 17:27:31 UTC