monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Derek Scherger
Subject: Re: [Monotone-devel] list branches on server?
Date: Sat, 22 Aug 2009 21:02:09 -0600



On Sat, Aug 22, 2009 at 11:49 AM, Timothy Brownawell <address@hidden> wrote:

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 been looking at this a bit, largely staring at netsync.cc to try and get a better idea of what it's doing though. Note that the net.venge.monotone.asio branch that zack started a while ago does not use boost::asio, but the standalone variant that does not require linking against the boost libraries as far as I can tell. It does seem to need -lpthread on linux though as asio apparently uses threads internally to simulate certain asynchronous operations.

See http://blog.think-async.com/2008/05/boostasio-vs-asio.html for more details on the non-boost asio variant.

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?

Pretty much everything at this point, as far as I can tell. I haven't found the asio docs to be all that great when trying to actually think in detail about how it will fit in to what netsync is doing, but on the surface at least asio seems fairly reasonable.
 
> 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?

Another thought on this that I've had floating around for a while is that perhaps rather than starting a second process and running netsync over stdio we could have two separate database instances open and sync between them from within a single process. I haven't looked at this in any detail at all so it might just be a crazy idea, but I think it would avoid all of the windows related network issues. Maybe some of the refactoring that zack and markus did a while ago relating to app_state, options and database arguments in various api's would make the idea of having two open database objects less crazy?

Cheers,
Derek


reply via email to

[Prev in Thread] Current Thread [Next in Thread]