On Wed, Nov 11, 2009 at 07:25, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
> RELPATH:
>
> A "relpath" represents "an unrooted path that can be joined to any other
> relative path, uri or dirent". Good, but let's specify it more
> precisely. The terms "absolute" and "relative" are not clearly defined
> when applied to partially-relative paths such as a Windows
> "\rel-to-current-drive" or a URL "/rel-to-server".
No. The intent is to NOT have any leading slashes. A relpath should be
"path/to/some/place". Change the docstring accordingly.
The intent is that a relpath is always attached to some root. For
Windows that could be "\". For a URL, that could be
"http://hostname/". Whatever. But never ever a leading slash.
>...
> URI:
>
> A "uri" in this API represents an "absolute path that starts with a '/'
> or a schema definition"... which is gratuitously specialized, compared
> with the official definition of a URI.
>
> We use URLs a lot and rarely need to use more general URIs, so I think
> the API should be geared specifically to URLs.
>
> It is not clear whether the representation of a URI is URI-encoded. The
> API should make a clear promise. I think it should be, both because
> that's a valuable part of the utility of a URL API, and because it seems
> unlikely to be possible to fully support URL manipulations without them
> being URI-encoded. (The sort of thing that springs to mind that simply
> would not work is if my password contains a "/" and I try to represent
> "http://username:password@my.org/" without URI-encoding.)
Bert has been making a bunch of changes throughout the codebase in
order to make the URI APIs take *only* absolute URIs. Never a relative
URI.
>...
> URLS:
>
> * Define and name functions for URLs instead of URIs.
Nope.
I spoke at length, last week, with Roy Fielding about this specific
topic. I explained our scenarios, and he recommended that we *stick*
to the URI name.
Sure, the APIs only deal with a subset of the URI space, but that
isn't a problem. Just document it as "we only handle <these> schemes".
And people aren't really using URNs anyway, so it doesn't matter much.
Over time, "the world" will converge on just the URI naming. We should
stick to the URI name in our APIs, and let the world catch up. Our
APIs are going to be around for a *long* time. Let's use the
correct/future names for it.
(and if you don't know who Roy is... he's one of the *primary* authors
of the URI specification; as far as I'm concerned, what he says goes;
I've found him to be rarely wrong, and you can ask Sander and Justin
to verify that :-P )
> * The representation of a URL should be always URI-encoded.
Yah. That's how we treat them, in general, but having it declared that
way would be good. As I noted above, we also want them to *always* be
absolute. The codebase is pretty darned close to allowing for that.
Also note that the svn_uri_* functions are new in 1.7, so we can
define them with this restriction.
>...
Outside of the above... *shrug*. Seems fine.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2416739
Received on 2009-11-11 21:37:10 CET