I have begun using the Python TorCtl package to develop a gui TOR controller. So, I am looking at the TorCtl source to understand how to use it properly. In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes?
Will the devs accept patches to remove unused code. I'm looking at you, TorCtl.TorUtil.Enum.
Is there interest in making TorCtl into a more mainstream form of Python package? See https://trac.torproject.org/projects/tor/ticket/2585
How far back in Python versions are we trying to maintain compatibility? As an example: TorCtl.TorUtil.Callable seems to be used to create static methods, but the staticmethod function to do this was added in Py2.2 (Dec 2001) and the @staticmethod decorator form was added in Py2.4 (Nov 2004).
And thank you for TorCtl, it certainly saved me time not to have to implement a protocol engine from scratch.
I have begun using the Python TorCtl package to develop a gui TOR controller.
Great! What are your planned use cases for this gui? Kamran is also beginning work on a gtk gui for arm (http://www.atagar.com/arm/ - a python project that uses torctl) so that might be of interest too. We'd certainly be glad to have the help.
Btw, there's also a wrapper library: https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py
which provides caching improvements, pid fetching, reattachability, and an expanded api on top of torctl. At some point I should turn this into a standalone library but its never been a high enough priority...
In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes?
Changes need to support backward comparability but besides that it's all good (commenting and var renaming of course are safe). It will be up to Mike to decide if the changes are accepted or not.
Will the devs accept patches to remove unused code. I'm looking at you, TorCtl.TorUtil.Enum.
I'm not sure, up to Mike.
Is there interest in making TorCtl into a more mainstream form of Python package?
TorCtl already has been packaged for Debian (the python-torctl package) so a big advantage of a distutils installer have already been covered. I'm not sure if there's interest in an rpm or distutils for standalone installation.
How far back in Python versions are we trying to maintain compatibility?
Definitely back to 2.4, I'm not sure how much further than that.
Cheers! -Damian
On Sat, Jun 11, 2011 at 12:28 PM, Damian Johnson atagar1@gmail.com wrote:
I have begun using the Python TorCtl package to develop a gui TOR controller.
Great! What are your planned use cases for this gui? Kamran is also beginning work on a gtk gui for arm (http://www.atagar.com/arm/ - a python project that uses torctl) so that might be of interest too. We'd certainly be glad to have the help.
The one feature I really, really miss from Tork is the Tor Console http://sourceforge.net/dbimage.php?id=95124. So, Syboa replicates that screen. I still have not decided whether I will try to release this software. But, I can still provide developer feedback for TorCtl.
In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes?
Changes need to support backward comparability but besides that it's
I completely agree. One of my first steps is to write unit tests for those parts I am tweaking so that I can verify behavior before and after changes. I, also, would like to submit these unit tests to the TorCtl package.
Is there interest in making TorCtl into a more mainstream form of Python package?
TorCtl already has been packaged for Debian (the python-torctl package) so a big advantage of a distutils installer have already been covered. I'm not sure if there's interest in an rpm or distutils for standalone installation.
I would encourage a distutils-compatible form. Since the Debian package seems to move the TorCtl modules into a distutils package form, it should make things easier for the Debian packager and other potential OS/distribution packagers. Also, this would enable developers on any platform to install just the TorCtl Python package with minimal work. Currently, (as far as I can see) the only way for a non-Debian-based developer to get TorCtl is through git clone.
How far back in Python versions are we trying to maintain compatibility?
Definitely back to 2.4, I'm not sure how much further than that.
I would agree that Py2.4 is a good threshold. I was afraid someone was going to want Py1.x compatibility.
The one feature I really, really miss from Tork is the Tor Console...
Gotcha. Arm provides similar information (application connections, your circuits, and much more via detail dialogs): http://www.atagar.com/transfer/tmp/connPanelWithCircuits.png
and the gui will be providing this information in a nice way like Tork (country flags, status indicators, etc). One thing that Tork has that I'm surprised by is the application connection to circuit mappings... I should look into how he does that.
Kamran: Have you looked at Tork yet for ideas on the gui? It's a lot different from Vidalia, providing different information in a very graceful way. I'd highly suggest it if you haven't yet.
Cheers! -Damian
-
Damian Johnson -
Sean Robinson