Thanks for the reply and the useful links! I went through txtorcon and stem a bit. Also skimmed through the control spec a bit. I'll now give an overview of what this project is, please correct me if I got something wrong. So basically tor has a control protocol that allows clients to connect to it, the spec is in the control-spec doc. txtorcon is a twisted-based implementation of this protocol. The aim of this project would be to use the protocol-parsing from stem instead of using the "re-implementation" in txtorcon. Since the protocol parsing is synchronous anyway(AFAICT) it makes sense to do this. Therefore, it would also make sense to identify other synchronous activities being done by txtorcon and use Stem to do those too (since we will be instantiating a stem object anyway). So as I see it, the majority of the changes will be in torcontrolprotocol.py(https://github.com/meejah/txtorcon/blob/master/txtorcon/torcontrolprotocol.p...) and in that in the TorControlProtocol and TorProtocolError parts(mainly) These classes have some functions that are used by others and some which are for internal use(i guess the ones with _ are internal if I got the naming convention right). So we will just throw away the internal functions(should we?) and keep the external function api the same, the difference being these external functions will now call stem instead of doing the heavy lifting themselves.
I have a question about LineOnlyReciever - Are there other types of receivers which txtorcon doesn't implement but stem does? If we are integrating the two it would be good to optionally add API's for these. Is this the primary reason for doing this integration? Or is it just better for tor if all the protocol specific code is one place so that it is easy to adapt to any changes in the API?
So in essence i guess my questions is - What is the primary focus of this project - Is it to bring the protocol specific code in one place or to use Stem wherever possible? or both?
Thanks, Regards, Anshul