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

[Robin Farine]

>>>>> zander  writes:

    > On Sun, Nov 23, 2003 at 08:30:57AM -0800, Tom Lord wrote:

[...]

    >> and say that only these two are right (with the /// fix):
    >> 
    >> >>       file%umask=XXX:///path/to/your/archive
    >> >>       sftp%umask=XXX:/address@hidden/path/to/your/archive

[...]

    > don't use this way unless you want to invent something new which
    > can not communicate with anyone else.

I was tempted to say something like this and to propose to use a URI
compliant form [rfc2396] like:

    file:///path/to/your/archive;uname=XYZ
    sftp://address@hidden/path/to/your/archive;uname=XYZ

which, according to the rfc, means that the (uname,XYZ) pair
parameterizes the path segment "archive".

And then there is rfc1738 which describes restricted forms of URIs
such as URLs for well-known schemes like 'file', 'ftp' and 'http'.
According to this document, a 'file' URL cannot contain parameters or
query part. An 'ftp' URL can only have one parameter associated with
the last path segment (type=<ftptype>) and cannot contain a query
part.

So, this implies that my proposal would also invent something new (I
think rfc1738 adds gratuitous restrictions and should be updated in
this regard), but at least the URI conforming form can be parsed by a
generic URI handling component.

Such a component would rely on scheme-specific pluggable parsers to
split a URI into parts and, in the Arch case, the resulting structure
would be passed to the appropriate pfs instance long with the original
URI. Then, based on the capabilities of the transport, the pfs
instance would handle parameters like 'umask' on the client side
(file, ftp, sftp) or just pass them to the server (http).

In the hypothetical case of a scheme with both the client and server
sides capable of handling such a parameter, then an additional
(dumb=<bool>) parameter could tell the client to interpret other
parameters or to let the server do the job.


Robin