[Monotone-devel] Re: netsync connection info cleanup

[Thomas Keller]

Am 28.04.2010 01:42, schrieb Timothy Brownawell:
>> 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
> 
> Seems reasonable.
> 
>> 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.
> 
> Is the occasional backslash really that bad? '%' conflicts with
> urlencoding 

Thomas Moschny pointed out later the possible conflict '%' has - but
there is a similar conflict with "+" as well, which stands for the
single '+' as inclusion character:

  php -r "echo urldecode('http://foo.de/+foo/-bar');"

> (and '*' would only actually glob things if you have some
> really weirdly named files)

zsh does glob unfortunately:

$ echo mtn://foo.com/foo*bar
zsh: no matches found: mtn://foo.com/foo*bar

bash does not apparently.

>, and '?' is probably necessary for file/ssh sync.

There are not many good characters left which are both intuitive and not
conflicting with either URL decoding nor command line pasting. I'm open
for further suggestions here.

>> 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://address@hidden/...
> 
> Don't we use the user part properly already for ssh sync?

Yes, forget it, it would confuse people and is bad design.

>> 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)
> 
> I don't think logic relying on this would play nicely with file/ssh
> sync, where there can be any number of path components.

We could parse the path up to \.(db|mtn), but yes, this would become messy.

>> 3) use a special character to denote the server instance, f.e.
>>     mtn://monotone.ca/~monotone/...
> 
> This could work except for our interpreting '~' in file/ssh sync.

We could pick a different character like '=' or '_'... since we disallow
the latter to be the first part of a branch pattern, this could work as
well.

> 4) require a '+' before the inlcude patterns (as shown in your
>    later examples). Yeah '+' is used in place of ' ' in URLs, but
>    we'd be deprecating use of spaces in branch names anyway.

And we'd have to treat any incoming "/ foo" as "/+foo" in case something
got url-decoded in the meantime. But yes, this could work as well.

>> 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
> 
> It looks like a path, but it isn't (entirely) a path. That seems
> horribly counterintuitive and a rather bad idea.
> 
> I suppose any '+' in the actual filename would have to be urlencoded (to
> not be taken as a space) and spaces can be done as '%20' as well as '+',
> so it's really only very slightly ambiguous unless someone puts the
> exclude pattern first, but still the lack of clear separation between
> "what we're talking to" and "what we're talking about" is a bit
> disconcerting.

Hrm... I'd love to see a URI syntax where the command line escaping
could be skipped for the 90% use case (pulling one certain branch from a
remote database, no wildcards included) - but if "?" is still part of
the pattern, its rather hard to achieve this.

What if we change the pattern separators to be a different character
than "/", like ":"?

   mtn://foo.bar:+foo.bar*:-foo.bar-baz

We'd also have no disambiguation problems with the server part then:

   mtn://foo.bar/server:+foo.bar*:-foo.bar-baz

and ssh:// paths would look like this:

   ssh://address@hidden/path/to/remote/db.mtn:+branch:-branch

If you do not particularily like ":" I could also imagine another
character here...


Thanks for your feedback!
Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | 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

signature.asc
Description: OpenPGP digital signature