Re: [Monotone-devel] url schemes

[Markus Schiltknecht]

Hi,

Timothy Brownawell wrote:
> For ssh transport the remote system would have to send back the db path
> it found, so we'd know where in the URL to start looking for parameters.
> Putting parameters into the query string instead of appending them to
> the path gets around this rather nicely.

That's not a big deal for ssh, IMO. We have a clever server at the other 
end, so we better use it.

> If the dumb server is being accessed through monotone, we can translate
> the provided URL however we have to.

Sure, computers can transform to whatever they want. But humans are 
easily confused by such transformations. IMO the URL scheme we are 
discussing here shouldn't be made easy for the computer, but should be 
designed to be easy for the human.

> >   * mtn should feature a simple API for 3rd party tools
>
> Isn't this what 'mtn automate' is supposed to be for?

Yes, automate is a good API for local 3rd party tools. Now lets make 
that remote accessible. With the presented URL scheme, we could pretty 
easily provide each and every automate command remotely.

> >   * faster and firewall compatible protocol (covered by nuskool)
>
> Faster is good, but it doesn't always make sense to tunnel everything
> over HTTP.

Agreed. However, I don't think of nuskool being limited to http. See the 
'channels' abstraction I've added between gsync and the http stuff.

> I think cert refinement in particular probably isn't a good
> match.

Well, put your certs in a DAG and nuskool fits perfectly well. (That's 
not my own idea, it's Graydon's).

> >   $DB/$BRANCHNAME for mtn://
> >
> > but:
> >
> >   $DB/branch/$BRANCHNAME for http://
> >
> > ..which would certainly confuse people.
>
> netsync doesn't take branch names, just patterns (some of which may be
> equivalent to branch names).

Then let's call in $BRANCHPATTERN, however, I'm still voting for 
"net.venge.monotone" - as such a pattern - to mean "that branch and all 
it's children".

First, because it's much simpler for people who don't care much about 
whether it's a branch or a branch pattern. And second, because fetching 
a branch needs to fetch the merged child branches anyway.

> There needs to be a clear separation between the db path and any
> parameters. http://host/path/to/app/followed/by/parameters can work for
> web apps because all processing of the URL happens on the server, which
> already knows do discard /path/to/app when looking for parameters. We
> can't do that, because the netsync client also needs to know the
> parameters.

For current netsync code that might be the case, yes. But, it's 
certainly not that difficult to make the server tell the client a 
repository base URL.

Let's design URLs that are nice to humans, not nice to our code, as it 
happens to be at the moment!

Regards

Markus