All righty... I relent. For now. :-)
Cheers,
-g
On Thu, Dec 21, 2000 at 07:59:59AM -0600, Karl Fogel wrote:
> 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.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006