Re: workspace header, labels, python client wanted

   From: Edgar@EdgarSchwarz.de

   Geoff gave some nice reasons for making labels optional.
   > operation.  If you want labeling, just get a server that supports it,
   > and then it's easy for a client to expose it, since we've standardized
   > on what labeling looks like when it is supported.  

   An advantage of making labels optional naturally is that a server
   can decide to implement workspaces and baselines and instead save
   itself the trouble of implementing labels.

That's a good point ... I know of at least a couple of systems that
support baselining but not per-version labels.  And even when a server
supports both baselines and labels, a client is *much* better off to
use the server's native baseline support, since a good server will
implement baselining in a far superior way natively than can be done
by a client using the servers labeling mechanism.

   Nevertheless I would
   like to see labels in core versioning as a simple means for
   creating baselines.

Note: In general, I'd discourage a client from trying to "fake"
baselines on a server that supports labels but not baselines.
If the label implementation was truly suitable for supporting
baselining (and many are not), then a sensible server writer will
do the trivial amount of extra work to support the baselining
protocol.  So it is very likely the only time you will run into
a server that supports labels and not baselining is when the label
implementation does not support effective (efficient) baselining.
But that of course is up to the client writer ... heck, you could
try to fake all of WebDAV on top of GET and PUT if you really 
wanted to (it just wouldn't work very well :-).

But even if you decide to fake baselines on with labels, all that
making labels optional would mean is that you would grey out
your baselining functionality if neither baselines or labels
were available.

   Then there is the question of case significance in labels. I would
   prefer case significance. Especially when I read about the trouble
   with capitalizing letters which don't have an upper case.  There
   was a long discussion a while ago and I guess that Geoff takes as a
   consensus that the server can decide what to do. That right Geoff ?
   In this case I see a small problem when resources with labels are
   moved from a server which supports labels with case significance to
   one which doesn't. But perhaps the market can rule again in this
   case ?

   > Yeah, I was a strong advocate of Workspace headers too, until
   > I ran into those pesky technical problems ... (:-).

   So you will probably want to kill workspace headers completely.

Yes.

   I just thought whether it would make sense to save it by saying it doesn't
   apply for the method URL. So the server still could find out which subtree
   and by this which module would be concerned. A drawback would be that
   the method URL would be a special case but I suppose there are bigger
   problems (Sorry to ask but I don't have time at the moment to get all
   the postings I missed the last months).

Yes, the problems arise for all URL's whether it is the request URL,
a URL in a header, or a URL in the content.

   OTOH I don't like to parse a URL to find out whether it is in some workspace
   or not (Yes I know it's possible :-)

It's not so much a parsing issue (workspace URL's look like any other
URL) as it is a property or semantic issue.  In particular, every
version selector in a workspace has a DAV:workspace property which
tells you which workspace the version selector is in (if any).

   So you see that I have some gripes but these aren't showstoppers for me.
   I suppose I could live with them. It's the same with Lisa's proposal of
   killing some new methods. I was sympathetic with some of her ideas but
   won't fight for them to my last breath.

OK, then I'll mark you down in the "can live with it" column (:-).

Cheers,
Geoff

Received on Monday, 16 October 2000 17:51:48 UTC