Re: [Monotone-devel] list branches on server?

[Timothy Brownawell]

On Sat, 2009-08-22 at 12:31 -0400, Stephen Leake wrote:
> Timothy Brownawell <address@hidden> writes:
> 
> > On Sat, 2009-08-22 at 09:44 -0400, Stephen Leake wrote:
> >> Is there a way to list the branches in a database on a server, without
> >> downloading the whole database?
> >
> > Not yet, that happens after we move to ssl transport and enable
> > 'automate stdio' over the network.
> 
> That makes sense.
> 
> How is that going? I have some time to spend; can I help in some way?

I think dscherger is looking into using boost::asio
(net.venge.monotone.asio), which includes ssl support (I think including
client certificates, which we need) but would take us back to linking
against boost libraries again.

I have a branch net.venge.monotone.tbrownaw.serve_automate that makes
'automate stdio' available on an alternate network port. There might be
something in it that could be cannibalized, but we likely want
everything served over one port so it probably wouldn't be useful
directly.

The 'hello' sequence would need to be changed a bit to allow for picking
a particular service (netsync, 'automate stdio', possibly others). The
parts dealing with authentication could go away, since that would be
replaced by the ssl layer.

Moving to ssl/tls would break things like usher, so we need to make sure
that whatever library we use supports Server Name Indication[1] (don't
know if asio does this).

I suppose the thing to do would be to first migrate to asio (or some
other library) with the current netsync, and then once that's working
turn on the ssl parts and strip out the now-redundant hmac and
authentication stuff and check against the ssl client certificate
instead.

So the question is, what needs to be done on the asio branch? And how
can we mitigate the problems people have with linking against boost?

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

> I'd also like to get 'mtn sync file:' working on Win32; last I
> checked, that meant replacing netxx with boost::asio. Is that affected
> by the ssl transport change? 

My understanding is that they would go together very nicely.

> Which has a better chance of getting to main first?

It sounds like they might be arriving together.