Greg Stein <gstein@lyra.org> writes:
> > 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 think it's a fallacy to assume one will never have to worry about
conflicts. No namespace scheme can entirely prevent them, and the URI
scheme in particular suffers from being non-fork-friendly: when a
project forks, using its domain name as a prefix becomes misleading.
Someone has to change their namespace simply because they're not
hosted at the same place anymore (or not change their prefix, but then
the URI's are implying something that isn't true).
Also, URIs are long and complex. Developers have an easier time
dealing with shorter strings (say, "svn:" or whatever). And let's
face it, the bottommost representation *is* going to poke out at
people, especially at developers, so we shouldn't fool ourselves into
thinking this complexity will all be hidden. It won't be hidden for
us; therefore, simplicity and shortness have _some_ advantage...
I'm not saying URIs are fatally flawed as a namespace protection
scheme, but there are problems with them. The comparison with the
Java class naming scheme is particularly apt: I've seen classes run
into problems because the hosting organization changed and so the
class had to change names with it. But users were expecting the old
names. Frustration results. Blecch. :-)
> [...] excessive flexibility has no particular requirement.
There I just have to philosophically disagree. Excessive flexibility
has been very successful for a number of programs. Emacs comes to
mind. :-)
The principle I guess I'm supporting here is: if we're doing extra
work to *support* excessive flexibility, then that's questionable.
But if we're going to do extra work to *prevent* it, then that's even
more questionable.
In this case, there's some extra work on both sides. If we don't use
URIs, then you have to do an SVN<-->DAV mapping. That's extra work
for you, I freely admit. But if we do use URIs from the ground up,
then other parts of the code have to do extra work enforcing this
policy (adding or checking for prefixes whenever the user sets a
property name), plus people have to do more mental work because
they're now dealing with long, complex strings instead of short,
easy-to-read names.
IMHO, the latter is more total work & complexity than the former.
Received on Sat Oct 21 14:36:17 2006