I have uploaded yet another revision of my proposal. (Sorry about that!)
Hi Bang, thanks for the update. The present proposal suggests adapting arm to be the backend of the relay dashboard. We've tried something similar to this before, and it had some drawbacks.
In 2011 Kamran made a Tor GTK interface for GSoC...
http://inspirated.com/2011/10/04/summing-up-gsoc-2011
This was pretty slick, but coupling two separate UIs in the same codebase was messy and in this next arm release this UI is being removed. This was the right technical decision back in 2011 since Stem didn't exist at the time (so arm's torTools module was the only game in town for thread safe, cached controller interactions). Nowadays however we have a nice controller library we can take advantage of. Anything a relay dashboard needs should either be in your service or added to Stem.
Also, while snooping around the dev version of Arm, I've noticed a slight glitch in the _get_controller method of __init__.py in arm.util :
if not stem.util.system.is_running('tor.real'):
raise ValueError(msg('connect.tor_isnt_running'))(I'm running on osx) My tor process is named tor.real instead, hence, this raises an error stating that tor isn't running although it is.
changing it to
if not stem.util.system.is_running('tor.real'):
solves this problem. Is this an issue (because I'm not using a linux dist of Tor) or am I doing something wrong on my end?
Interesting. Any idea why your tor process is being called 'tor.real'? Is this something OSX related or is TBB naming its process that?
It sounds like we'll want to change this check to look for both process names, though I'd like to know a little more about this alternate name first. On a side note this check isn't having any functional impact - it just determines what kind of error message we present the user with.
Cheers! -Damian