[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
method.
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:
http-fs:.....
http-fs%umask=XXXX:
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.
-t
- Re: [Gnu-arch-users] multi-committer functionality revisited, (continued)
- Re: [Gnu-arch-users] multi-committer functionality revisited, Dustin Sallings, 2003/11/17
- Re: [Gnu-arch-users] multi-committer functionality revisited, Tom Lord, 2003/11/17
- Re: [Gnu-arch-users] multi-committer functionality revisited, Robert Anderson, 2003/11/17
- Re: [Gnu-arch-users] multi-committer functionality revisited, Robert Collins, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited,
Tom Lord <=
- Re: [Gnu-arch-users] multi-committer functionality revisited, zander, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Tom Lord, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Robin Farine, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Robert Collins, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Robert Collins, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Tom Lord, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, zander, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Tom Lord, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, zander, 2003/11/23
- Re: [Gnu-arch-users] multi-committer functionality revisited, Tom Lord, 2003/11/23