Re: netsync connection info cleanup Was: Re: [Monotone-devel] usher

[Timothy Brownawell]

On 04/15/2010 07:59 AM, Thomas Keller wrote:
> Am 15.04.2010 13:33, schrieb Thomas Keller:
> > I played around with [mtn://-style uris] further, there are a couple of serious 
> > bugs in
> > this feature. Apparently the uri scheme only works if a port (and may it
> > only be the standard port 4691) is given and thats also the reason why
> > the tests don't alert the problem, becase they always run a local mtn
> > instance on the non-standard port.
> >
> > Furthermore, known-servers gets the complete URI instead of just the
> > hostname set when the mtn uri is used:
> >
> > known-servers: mtn://guitone.thomaskeller.biz:4691
> > f814415176bf04178c64895b19ef99752159626d
> > known-servers:
> > mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone
> > f814415176bf04178c64895b19ef99752159626d
> >
> > This leads to new entries each time the branch pattern changes only
> > slightly and means also that the user is alerted of a "new server" each
> > time.

It needs to include everything up to the '?' I think. For file: or ssh: 
there could be different databases (on the same host for the case of 
ssh) that you want different patterns for (since it stores this now), 
and the default server would need to include the path if it's file: or 
ssh: .

> > I don't had the time yet to debug this further, I only re-assured that
> > parse_uri() itself doesn't seem to be the problem, because port-less
> > URIs are tested there and the test succeeds.
>
> I started a new branch (net.venge.monotone.connection_info_cleanup)
> where I tried to fix some of the issues. mtn://server-style URIs with no
> port should work already, also the known-servers problem has been fixed.
>
> 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.

> I'll try to refactor some of the code afterwards and move the parsing
> logic (also for include / exclude patterns) into
> netsync_connection_info. I started already by adding a get_port() method
> which either returns the default mtn port or a custom port parsed from
> the argument.
>
> Thomas.

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net