On Thu, Dec 21, 2000 at 12:24:27AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
> >> I guess I'm not clear on why you require it to be a URI?
> > To enable a 1-to-1 correspondence between SVN properties and DAV properties.
> > DAV props are named with a URI, so if we use a URI then there doesn't have
> > to be a DAV <-> SVN mapping of prop names.
> This would tie our public interface to the specifics of one network
> protocol, which AFAIK we decided against long ago. That would get a -1
> from me if it came to a vote.
It doesn't "tie" it. It uses the same logic as DAV to design how properties
should be named so you never have to worry about conflicts. It is a rational
and well-thought-out mechanism.
The side-benefit is easy integration. That is not the driver.
Again, my main argument is: use URIs so we don't have to worry about
conflicts; allowing arbitrary strings or (gasp) binary values is just an
exercise of developers saying, "well, we can do that, so let's go ahead!"
I excessive flexibility has no particular requirement.
Greg's UI issue is the closest, but I think we'll just end up agreeing to
disagree on that part.
> > The URI mechanism also prevents two tools from both using a property called
> > "name" and getting confused.
> So we can recommend the use of URIs for property names. We shouldn't
> enforce it.
And why not enforce it? It can help us, and it can help our users, and it
can help third-party tool developers.
What is the reason for *not* enforcing it?
> Sorry if this came over a bit strong, Greg, but I think DAV specifics
> are gainig a bit too much weight here. We should think about how DAV can
> be made to work for Subversion, not the other way around.
I'm a big boy... no offense taken :-)
However... Where is DAV impinging on SVN? Back that one up, or drop the
I have been striving quite diligently to keep DAV from impacting SVN (since
*March*, when I first proposed it to Karl). And if you really want to know,
I'm planning on using a custom "report" between the client and the server
which will effectively blast away any chance of interoperability with other
DAV clients/servers. That can be remedied (a bit expensively) in the future.
But for 1.0, we're taking the shortcut (and using stuff not in the DAV
specs) to avoid impacts on SVN.
Where do you see DAV affecting SVN's design?
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006