[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] multi-committer functionality revisited

From: Tom Lord
Subject: Re: [Gnu-arch-users] multi-committer functionality revisited
Date: Sun, 23 Nov 2003 15:49:46 -0800 (PST)

    > From: address@hidden

    > You are looking for the part where its made clear that
    >     file%uname=002:bla
    > is pointing to another port/application/implementation then
    >     file%uname=077:bla

Would it have been too much trouble for you to say:

        see section 1.2 where it says

           "Although many URL schemes are named after protocols"

which appears to be what you're talking about?  I mean that's it --
that _phrase_ (emphasis added) is the best support I can see for your
position.  Is there something else you're thinking of?

_Ports_ by the way are addressed in section 3.2.2 and "application"
and "implementation" are not used in the RFC in the senses that you
seem to imply.

Section 3.1 seems to me to be the most relevent to this and it 
supports my idea but demands a different syntax, using only permitted


I like that approach rather than using the other permitted punction (+
and -) because then:


can later have a distinct and useful meaning.

It seems unwise to try to put umask info in the <authority> part of
the url, especially for sftp and then for local files for consistency.
(See section 3.2.2 which defines a syntax for ip-based protocols to

The last remaining sane possibility (other than making up an entirely
new syntax for pahts) is to make the umask a parameter to some path


however, that seems fairly gratuitous and inconvenient to me.  
For example, I could not then cut and paste the stuff to the right of
the : into a file or sftp URL.   And if the path to my archive
contains a ;, then it would need to be escaped before being handed to 

It is, indeed, truly sad that the "scheme" syntax is sufficiently
anemic as to make parameterized protocols more difficult than
necessary to name but I see nothing that precludes them and they seem 
like a quite sane idea to me.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]