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

[Robert Collins]

On Mon, 2003-11-24 at 11:08, Tom Lord wrote:
>     > From: Robert Collins <address@hidden>
> 
>     > schemes aren't parameterised: they accept parameters in the
>     > query_part.
> 
> Schemes aren't _not_ parameterized.  The RFC is simply silent on the
> issue.

There is no allowance for parameters in the scheme portion. That's close
enough to not paramterised for me. If you want to build URI Version Tom,
thats your choice.

> Putting this or any other parameter in a query part or parameter part
> would mean that the scheme-specific parts of our URLs would not be
> compatible with sftp: and file: schemes -- which seems gratuitous to
> me.

point by point:
sftp: is only in draft format, and there is an explicit part to put the
parameter in - we will be compatible with the scheme specific part of
the standard sftp urls. (In that a parser that can parse sftp url's will
parse ours - not in that a client that parsers sftp urls will be know
what to do with the umask parameter).
> ander:
> 
>       file.uname077   not     file%uname=077
>         sftp.uname002 not     sftp%uname=002

that specifies the scheme "file.uname077". There is no IANA scheme for
that, nor an informal spec that I know of. Care to enlighten us? Ok, so
I'm being silly. You *mean* "file" with the extra detail that "uname
should be set to 077". The point is that the RFCs - 1738 and 2396 DO NOT
share that meaning with you. YES, the specs are limited in this fashion.
Passing a sftp.uname077://host/path url to an external tool - say a GUI
URL handler - will result in a failure. Passing a
sftp://host;uname=002/path url to the same tool will not result in a
failure. (assuming in both cases that the tool has been written to the
standard).


>     > That said, section 2 and 2.1 are quite clear - the scheme is a method of
>     > access to the location in question. If you write a cgi-on-http protocol,
>     > which can then be used to obtain access to arbitrary objects, you need a
>     > new identifier.
> 
> Right, like the `http-fs' scheme and `http-fs.unameXXX' schemes I suggested.

Yes. The point to note is that both of those schemes are -not- usable by
existing tools - mozilla doesn't know how to get a directory listing for
a http-fs url, or for a http-fs.unameXXX url. 

>     > The key point I am making is that the protocol scheme is not
>     > parameterised under any circumstance. 
> 
> Nothing says that.  In fact, we _already_have_ parameterized schemes
> in the case of:
> 
>       wu-ftp:         vs.     ftp:

Which is equally ugly. We've worked around a limitation in our client
implementation by hardcoding it's parameterisation according to the
scheme. (Yes, I know that the issue is the nature of the server
responses. the fact remains that curl, wget, and other cmd line tools
deal with wu-ftp servers quite happily via the ftp:// url scheme.)

>     > That said, I cannot find a umask command for sftp - only a 'lumask'
>     > command which sets the local umask.
> 
> The protocol allows you to change file attributes.

Right, so we can fake it. Gotcha.

> 
>     > Essentially: we were both wrong.
> 
> So far it looks like I was wrong only on a small matter of syntax :-)

pffft. I was wrong on syntax, you want to parameterise individual
connections by diddling with the scheme - breaking the whole point of
"Uniform" syntax.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part