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

[Robert Collins]

On Mon, 2003-11-24 at 03:30, Tom Lord wrote:
>     > From: Robert Collins <address@hidden>

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

Sorry, I wasn't clear. This is how url's are formed: there's no choice
about it.

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

A URL as a uniform locator isn't intrinsically client or server side.
Indeed for something like http://, a URL doesn't define *many* aspected
of the request: PUT vs POST ve GET cs SEARCH vs ....

> The query syntax, on the other hand, modifies the request, not the
> method.

No - it modifies the parameters to be used at the given location.

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

Gah. Where to start.

Lets debug sftp://host/path/archive?umask=007

For our current sftp transport, we define this to mean: use the umask
007 for any operations on the resources found at
sftp://host/path/archive. To implement that, the sftp scheme module in
tla must issue the sftp umask command during session setup.

So what does

http://host/path/archive?umask=007

mean?

Firstly, it's a different url scheme, so everything else is relative to
it's own definition. But for consistency, we'll choose the same
defintion for umask, and see if consistency problems occur:

we define this to mean: use the umask 007 for any operations on the
resources found at http://host/path/archive. To implement this, the http
scheme module must hand the parameter to the cgi script.

For your example of a cgi script that implements sftp commands, yes you
will need a new protocol scheme: you're not using http anymore (to do a
file upload in http you use PUT. To do a transaction with side effects,
you use POST)

so you would have 
arch://host/path/archive?transport=cgi&umask=007

Rob

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

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