[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 12:33:21 -0800 (PST)

    > From: address@hidden

    > > 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

    > > The reason for this is that the umask parameter modifies the method,
    > > not the request.  It is a client-side parameter that means, in effect,
    > > "don't use ordinary {sftp,file} -- use the {sftp,file} transport where
    > > you set the umask first".

    > Different layer of abstraction.  It belongs in the part after the colon
    > because it modifies something chosen after the part before the colon is
    > parsed.

    > How many many implementers did it before is that the part before the colon
    > is the 'name' of the service; and there is only a limited list.
    > If you want to list your imap mailbox from konqueror you can use the imap:
    > name, and pass various options to it by altering the url after the colon.

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

Don't confuse transport with protocol.

I stand by my statement.  The umask parameter is effectively a change
in protocol.  It so happens that the new sftp%umask=XXX protocol can
be correctly implemented on the server-side by an ordinary sftp
server, but that's essentially just a (convenient) coincidence.

Putting the umask parameter in the hostname part or as a query would
result in an invalid sftp uri, would it not?

The method part of a URI is what a client uses to decide how to
connect.  That decision needs the umask parameter -- its part of the


reply via email to

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