W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

workspace header, labels, python client wanted

From: <Edgar@EdgarSchwarz.de>
Date: Mon, 16 Oct 2000 17:25:49 -0400
Message-Id: <200010162125.RAA02314@tux.w3.org>
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
Hi,
I have a couple of questions.

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.  
> (I'm tempted to make an analogy about the superiority of "market driven"
> economy over a "command" economy :-).
When I see how the "market" is taking care that programmers aren't too
productive but struggle against badly designed hardware and operatings system
I'm not sure about this superiority in some cases :-)
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.
Nevertheless I would like to see labels in core versioning as a simple
means for creating baselines.
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.
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).
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 :-)

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.

Fianlly a question. A collegue of mine is doing a lot with Python. After
looking over www.webdav.org I mailed Jim Davis about the Python client
mentioned there. 
But it's source is not free. Does anybody know about a free Python client ?

Cheers, Edgar



-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein
Received on Monday, 16 October 2000 17:25:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT