[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 08:30:57 -0800 (PST)

    > From: Robert Collins <address@hidden>

    > > While I would be against the "copy permissions" hack and against a
    > > "tla umask" command, I would not be against support for archive=20
    > > URLs of the forms (suitably adjusted if I've violated uri syntax):

    > >         file%umask=XXX://path/to/your/archive
    > >         sftp%umask=XXX:/address@hidden/path/to/your/archive
    > >         sftp:/%umask=XXX,address@hidden/path/to/your/archive

    > file:///path/to/your/archive?umask=XXX
    > note the /// <- this uses an implied localhost for the host portion of
    > the uri.

    > sftp://address@hidden/path/to/your/archive?umask=XXX

    > http://address@hidden/path/to/archive?umask=XXX

    > etc.

    > the ? delimits the abs_path from the query_part.

Yes, I thought about that, but I do not think it is correct.   In
fact, for the same reason, I withdraw the suggestion of this syntax:

    >>  sftp:/%umask=XXX,address@hidden/path/to/your/archive

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

The query syntax, on the other hand, modifies the request, not the

Consider a hypothetical future extension of vanilla HTTP support:  we
finally get around to having some CGI-scripts that allow writes over
vanilla HTTP.   Imagine that it works isomorphically to sftp -- it is
basically just "an sftp-like file-system over HTTP" CGI script.

In that case, most likely, there's a use for the query syntax that
will really call for server-side implementation.   And if we want a
umask-setting varient on that for arch archives, then there's two
choices:  either follow the existing pattern and do that client side
or suddenly build that as a "special case" into the otherwise generic
CGI scripts.   I think the former (client side) is obviously the
cleaner approach but now the URI syntax matters:  are we going to have
_some_ query elements picked out client-side and others server-side?
or just:


Now, maybe there's already some URI syntax I'm not aware of for
handling "parameterized methods" and, if so, that's preferable to my
'%' syntax but still, this modifies the method, not the query.


reply via email to

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