[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Final(?) Relative Externals format

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-24 22:40:02 CET

Max Bowsher wrote:

> André Malo wrote:
>> * Max Bowsher wrote:
>>> Hmm. I really don't like the concept of a scheme which actually isn't a
>>> scheme, it's a modification applied to some other implied scheme.
>>> /// makes more sense to me.
>> I tend to disagree. It represents a specific addressing scheme (of a
>> subversion resource) independent from any physical access. A bit like
>> mailto:.
>> Further I don't consider /// as compliant, because there is no rule
>> in RFC
>> 2396, which defines a triple slash at the beginning -> it could be
>> rejected
>> by a strictly compliant URI parser.
> Only subversion will ever have the ability to correctly interpret
> these URL-like things, so I don't see the above as a problem.
> RFC 2396 never envisaged something filling this role, so I don't see
> any problem with exploiting syntax it left undefined to cater to our
> needs.
> I don't view this as suitable for a scheme, because scheme: implies an
> absolute URL, and this is not absolute. (A mailto: is absolute).

Absolute, yes, but in the context of the scheme's meaning. It doesn't
have to be "absolute on the net". Witness Mozilla's use of the chrome:
scheme to access GUI resources -- those URLs are absolute in the sense
that chrome: implies a chroot to the installation's resource database.
In the same way, in-repos: would imply a chroot to the top of the
current repository.

Also witness DAV's use of opaquelocktoken: -- it's only meaningful
within a single server.

I'm not saying that using a scheme is better than the triple-slash
construct, only that this usage is not unheard of.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 24 22:42:34 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.