I don't have any feedback on this stuff myself, but I want to mention that over a year ago, Roland McGrath posted some complaints about the mtn:// URI schema being either broken or not useful as designed -- it was never clear to me which, because I don't know how it's supposed to work. You might want to dig back through the list archives and see if you can't address his concerns as long as you're messing with this stuff.
zw On Sun, Apr 18, 2010 at 11:49 AM, Thomas Keller <m...@thomaskeller.biz> wrote: > Am 18.04.10 04:34, schrieb Timothy Brownawell: >> On 04/15/2010 07:59 AM, Thomas Keller wrote: >>> However there is a bug in our parse_uri() implementation: If no scheme >>> (f.e. mtn://) is given, it treats the string as path rather than as >>> hostname. This leads to the problem that the scheme-less default server >>> setting we store in the db vars is not treated correctly and that a host >>> which is entered by the user is now also parsed wrongly. >>> As I said, I'd rather change the implementation of parse_uri than >>> forcing the user to pull "mtn://monotone.ca" instead of just >>> "monotone.ca"... >> >> This should work now. parse_uri() will check for things that look like >> only a hostname or ip address and maybe a port, and skip most of the logic. >> >> It also uses everything before the query string in the db vars, and also >> uses that for the 'peer' string in the network session. This is what >> gets sent to the usher, so giving >> mtn://monotone.ca/foobar?include=... >> would send "mtn://monotone.ca/foobar" to the usher where it currently >> sends only the hostname (and the normal way of "mtn sy monotone.ca ..." >> would still send just the hostname), which should make it possible to >> use usher with neither wildcard dns nor pattern-based dispatch. > > There are still a couple of quirks in the url parsing code - f.e. > path-like (invalid) URIs like the following one are accepted (it will > only fail if no default branch pattern is stored in the DB): > > mtn://monotone.ca/monotone/net.venge.monotone\ > /-net.venge.monotone.guitone > > which end up creating completly wrong default server entries. I think we > should define first what we want to allow and how it should look like > here. A small nuisance is f.e. that the "?" in the URI makes problems on > some shells (at least zsh), so you need to quote the complete string. > We've "supported" that use case halfwhat in the past by not using "&" as > query separator, but "/", but I think we can further improve this. > > The following URIs are currently supported: > > mtn://monotone.ca > mtn://monotone.ca/monotone > mtn://monotone.ca?foo.bar > mtn://monotone.ca?foo.bar*/-foo.bar.baz > mtn://monotone.ca/monotone?foo.bar > mtn://monotone.ca/monotone?foo.bar*/-foo.bar.baz > mtn://monotone.ca?include=foo.bar > mtn://monotone.ca?include=foo.bar*/exclude=foo.bar.baz > mtn://monotone.ca/monotone?include=foo.bar > mtn://monotone.ca/monotone?include=foo.bar*/exclude=foo.bar.baz > > The first unfortunate thing here is that we have to support two > different syntaxes, one time you can omit "include=" and replace > "exclude=" with a "-" and one time these can be given (probably because > we advertise that people could use weird branch name patterns which > don't follow the reverse dns scheme almost everybody uses, but this > doesn't seem to work correct either, try f.e. > "mtn://monotone.ca/monotone?include=foo/bar/baz*/exclude=foo/bar/baz/bla"). > > The second unfortunate thing is that the "short" syntax, while being > less verbose, still needs quoting because of "?" as the query separator > and "*" for branch expansion. > > > So how should we continue? I think we should pick _one_ syntax and stick > to that, and I'd vote for the simple one > > mtn://monotone.ca?foo.bar*/-foo.bar.baz > > but with a few modifications so it would look like this: > > mtn://monotone.ca/foo.bar%/-foo.bar.baz > > (or explicitely mtn://monotone.ca/+foo.bar%/-foo.bar.baz) > > Here no comand line quoting is needed at all and the SQL-like "%" > wildcard should be recognizable as well. > > Secondly, I'd actively deprecate any branch name which does not match > the following regular expression, i.e. by throwing a warning when a > branch cert which a different value is created: > > ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ > > (test script to play around: http://pastebin.ca/1866605) > > This way we ensure that a branch name later does not conflict with the > URI separator nor with the wildcard character nor with the negation we > need for branch exclusion in our URI scheme. > > Thirdly I'd unify the way includes and excludes are defined for netsync > commands. I'd deprecate the "SERVER BRANCH [--exclude=PATTERN [...]]" > options (but would leave them available and convert them to the internal > representation with "%" as wildcard f.e.) and I'd make the new URI > available for all commands (currently clone does not support the old > URIs f.e.). > > > Lastly, the only thing which has not yet been determined is how we can > represent the server notion for usher - clearly this would conflict with > the new branch pattern, ie. does > > mtn://monotone.ca/monotone/net.venge.monotone > > mean > > a) server instance monotone, branch net.venge.monotone - or > b) default server instance, branches monotone and net.venge.monotone > > I can think of several solutions: > > 1) "misuse" the user part of the url, ie. mtn://monot...@monotone.ca/... > 2) make the server part mandatory and the first part of the path, ie. > mtn://monotone.ca/monotone (or mtn://monotone.ca// or > mtn://monotone.ca/default or whatever) > 3) use a special character to denote the server instance, f.e. > mtn://monotone.ca/~monotone/... > > > Finally, how do other URIs (not based on the mtn:// protocole look like? > Well, I'd probably simply append them on the original one, like so: > > file:///path/to/db.mtn/+branch/-branch - and > ssh://server/~/db.mtn/+branch/-branch - or > ssh://server/path/to/remote/db.mtn/+branch/-branch > > What do people think? > > Thomas. > > -- > GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz > Please note that according to the EU law on data retention, information > on every electronic information exchange might be retained for a period > of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en > > > _______________________________________________ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel > > _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
