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://monot...@monotone.ca/... > > 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://u...@server/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 | 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel