On Thu, Jul 25, 2013 at 5:23 PM, Damian Johnson <[email protected]> wrote: >> Actually, I think we have a path to get to a less-pure-C Tor >> implementation. For sandboxing reasons, we'll want to move Tor to >> work as a set of multiple processes that communicate over well-defined >> IPC interfaces via a master process. Once we get there, it's no >> longer too much to think about doing some of those processes in a >> language other than C. > > Neat! I didn't know we had plans around this. Is this on the horizon > or off in unscheduled wishlist territory? If this starts with > descriptor or controller functionality then I'd be interested in > helping.
Somewhere in the middle. The sandboxing is now; the partitioning is "not too long I hope"; the multiprocess-transition is "after that, as possible"; and the reimplementation of bits and pieces is "time permitting, as relevant." >> (What I'm *not* thrilled about is the idea of using an embedded >> interpreter for this kind of stuff, or embarking on any direction that >> requires us to rewrite too much of the program at once. That way, in >> my opinion, lies long-term destabilization.) > > Understandable, though doesn't avoiding an interpreter drop most > modern languages from consideration (and any sandboxing an interpreter > would provide)? What did you have in mind instead? What Brandon said here, plus I'm not opposed to an interpreter, but an _embedded_ interpreter (that is, one running in the same process space as all the rest of the Tor code). yrs, -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
