Re: [tor-dev] A few ideas about improved design/modularity in Tor

2016-04-03 Thread meejah
Nick Mathewson writes: > ZeroMQ and its competitors are pretty good, but overkill. They're > designed to work in a distributed environment where with unreliable > network connections, whereas for this application I'm only thinking > about splitting a single Tor instance across multiple processes

Re: [tor-dev] A few ideas about improved design/modularity in Tor

2016-04-03 Thread Nick Mathewson
On Mon, Mar 28, 2016 at 6:49 AM, Rob van der Hoeven wrote: >> 2. Add backend abstractions as needed to minimize module coupling. These >>should be abstractions that are friendly to in- and multi-process >>implementations. We will need at least: >> >>- publish/subscribe{,/acknowledge}.

Re: [tor-dev] A few ideas about improved design/modularity in Tor

2016-03-28 Thread Rob van der Hoeven
> 2. Add backend abstractions as needed to minimize module coupling. These >should be abstractions that are friendly to in- and multi-process >implementations. We will need at least: > >- publish/subscribe{,/acknowledge}. > > (See > https://en.wikipedia.org/wiki/Publish%

[tor-dev] A few ideas about improved design/modularity in Tor

2016-03-25 Thread Nick Mathewson
(Hi! Here's a document I've been poking at , on and off, for a while. There's a lot more to say here, but I think it's ready to share with tor-dev for comment. Thanks!) ++ +++ 0. PRELIMINARIES. +++