On Wed, Dec 20, 2000 at 03:14:17PM -0500, Greg Hudson wrote:
>...
> > Can somebody give a rational reason for not using URIs for prop
> > names?
>
> I think it's a heavyweight solution to a fairly small problem.
"heavyweight" is an arguable term to apply :-) I see a URI as an opaque
string. Things such as "prop-name" are also opaque strings. One is a bit
longer, and has unique-ness properties. It doesn't have to resolve in a web
browser, and it doesn't have to follow any particular organization (beyond
URI requirements of "scheme:scheme-specific-stuff").
> We
> don't use URIs for our C function names, for instance; we assume the
> "svn_" prefix will be good enough.
I'd say that we don't use them because our tools don't support it. :-)
Look at the Java world. They use URI-like naming for their stuff. Consider
"org.apache.slide.*" vs "com.ibm.*". People are using their domain name as a
unique identifier, much like a URI does.
Within C code, we *attempt* to be unique by using special prefixes (ap_ for
Apache, apr_ for APR, svn_ for Subversion). But we don't really have any
guarantee. Look at the C++ "namespace" thing -- that is an attempt to add
more uniqueness to the names.
In other words, programmers are *striving* for the uniqueness of URIs in
their naming, but the tools only go partway. Out-of-band "policy" assists in
this (e.g. a policy is the Java naming, or selecting a prefix).
> Property names do get presented to
> the user (they don't have to be presented to the user exactly as
> stored, but what is presented to the user needs to be just as unique
> as what is stored), and presenting a URI is both confusing and
> obfuscating--confusing because the user might think the URI would mean
> something to a web browser, and obfuscating because there's a lot of
> crud in there besides the interesting part of the property name.
That is a UI issue, not a reflection of problems in the underlying
mechanics.
Consider the two properties that libsvn_ra_dav stores into the local
prop-store:
http://subversion.tigris.org/props/ra/dav/local/activity-url
http://subversion.tigris.org/props/ra/dav/local/version-url
That is quite a mouthful, but I can guarantee that it won't conflict. I tend
to agree that it is also a bit hard for users to deal with. But *only* if
you make them spec the whole thing. Simple answer? Just show the last part:
$ svn propget some/dir
activity-url = http://www.lyra.org/repos/$svn/act
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
version-url = I'm a dumbass
$ svn propget -v some/dir
http://subversion.tigris.org/props/ra/dav/local/activity-url = http://www.lyra.org/repos/$svn/act
http://subversion.tigris.org/props/ra/dav/local/version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
http://www.dumbass.org/svnprops/version-url = I'm a dumbass
$ svn propget some/dir activity-url
activity-url = http://www.lyra.org/repos/$svn/act
$ svn propget some/dir version-url
Warning: multiple name matches
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
version-url = I'm a dumbass
$ svn propget some/dir "*subversion*/version-url"
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
[gjs: an example of "globbing" for prop names]
$ svn propset some/dir activity-url http://this/will/break/things
[gjs: this could update the existing prop when found]
$ svn propset some/dir my-prop foobar
$ svn propget some/dir my-prop
my-prop = foobar
$ svn propget -v some/dir my-prop
http://subversion.tigris.org/svnprops/user-named/my-prop = foobar
$ svn propset some/dir version-url blather
Error: multiple name matches -- a more specific name is required
etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006