[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] url schemes

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] url schemes
Date: Sun, 23 Mar 2008 12:22:28 +0100
User-agent: Mozilla-Thunderbird (X11/20080109)


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

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


  $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

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!



reply via email to

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