This part isn't actually true. We review each other's code, and don't merge stuff without reviewing it. Further, Andrea is full-time on the tor codebase, just like me. The code review slows us down a fair bit, but we do do it.
My bad then. From interactions on tickets and commit history it simply seemed like you are far and most the primary person engaged with the codebase...
atagar@odin:~/Desktop/tor/tor$ git log HEAD~200.. | grep "^Author:" | sort | uniq -c | sort -rn 404 Author: Nick Mathewson nickm@torproject.org 40 Author: Andrea Shepard andrea@torproject.org 25 Author: Roger Dingledine arma@torproject.org 20 Author: Mike Perry mikeperry-git@fscked.org 12 Author: Karsten Loesing karsten.loesing@gmx.net ...
Of course commits are roughly as meaningful as lines of code for involvement (which is to say, they're meaningless). Just the stat I had handy. Besides that Andrea hasn't sent a status report since March so I haven't a clue what she's up to.
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.
(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?
Cheers! -Damian