Hi Damian,
Thank you for your feedback and suggestions!! I have revised my proposal and uploaded it to melange.
Cheers Bang
Hi Damian,
Just updated a new revision of my proposal on melange. Looking forward to more feedback on how I can improve it and what direction I should approach this project!!
Cheers Bang
On Fri, Mar 21, 2014 at 10:14 PM, Bang Hui Lim limbanghui@gmail.com wrote:
Hi Damian,
Thank you for your feedback and suggestions!! I have revised my proposal and uploaded it to melange.
Cheers Bang
Just updated a new revision of my proposal on melange. Looking forward to more feedback on how I can improve it and what direction I should approach this project!!
Hi Bang. Thanks, this is certainly an improvement! However, I think there's some confusion about the present state of arm...
The main bulk of the work would be to port Arm's functionality away from TorCtl.
Arm's development codebase has already been ported from TorCtl to Stem. It's a bit of a mess right now from the overhaul, but functional...
https://gitweb.torproject.org/arm.git
First would be to design the user onboarding flow - how the user gets from selecting a certain configuration to managing the views.
I'm not sure what you mean in this paragraph.
The reasons for choosing the micro web framework is because it is lightweight and flexible and fulfills the basic needs required to make this web relay dashboard work.
Sounds good.
19 May - 25 May - Initial Architecture of Relay Web Status Dashboard, Discussion and review with mentor
Actually, this is what I'm hoping for the proposal to cover. ;)
26 May - 8 Jun - Porting of Arm modules from TorCtl to Stem
Again, this is already done.
Cheers! -Damian
Hi Damian,
Arm's development codebase has already been ported from TorCtl to Stem.
It's a bit of a mess right now from the overhaul, but functional...
Omg yes, you are right! I realize I was looking at the source for the release version instead :( . Thanks for pointing that out!
First would be to design the user onboarding flow - how the user gets
from selecting a certain configuration to managing the views.
I'm not sure what you mean in this paragraph.
I will try to make things clearer in my next revision.
19 May - 25 May - Initial Architecture of Relay Web Status Dashboard,
Discussion and review with mentor
Actually, this is what I'm hoping for the proposal to cover. ;)
Sounds good!
I will continue working on the proposal. Thanks for taking the time to review it!
Cheers Bang
On Sun, Mar 30, 2014 at 6:00 AM, Damian Johnson atagar@torproject.orgwrote:
Just updated a new revision of my proposal on melange. Looking forward to more feedback on how I can improve it and what direction I should
approach
this project!!
Hi Bang. Thanks, this is certainly an improvement! However, I think there's some confusion about the present state of arm...
The main bulk of the work would be to port Arm's functionality away from
TorCtl.
Arm's development codebase has already been ported from TorCtl to Stem. It's a bit of a mess right now from the overhaul, but functional...
https://gitweb.torproject.org/arm.git
First would be to design the user onboarding flow - how the user gets
from selecting a certain configuration to managing the views.
I'm not sure what you mean in this paragraph.
The reasons for choosing the micro web framework is because it is
lightweight and flexible and fulfills the basic needs required to make this web relay dashboard work.
Sounds good.
19 May - 25 May - Initial Architecture of Relay Web Status Dashboard,
Discussion and review with mentor
Actually, this is what I'm hoping for the proposal to cover. ;)
26 May - 8 Jun - Porting of Arm modules from TorCtl to Stem
Again, this is already done.
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi Damian,
I have uploaded yet another revision of my proposal. (Sorry about that!)
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?
Thanks!
Bang Hui
On Sun, Mar 30, 2014 at 4:02 PM, Bang Hui Lim limbanghui@gmail.com wrote:
Hi Damian,
Arm's development codebase has already been ported from TorCtl to Stem.
It's a bit of a mess right now from the overhaul, but functional...
Omg yes, you are right! I realize I was looking at the source for the release version instead :( . Thanks for pointing that out!
First would be to design the user onboarding flow - how the user gets
from selecting a certain configuration to managing the views.
I'm not sure what you mean in this paragraph.
I will try to make things clearer in my next revision.
19 May - 25 May - Initial Architecture of Relay Web Status Dashboard,
Discussion and review with mentor
Actually, this is what I'm hoping for the proposal to cover. ;)
Sounds good!
I will continue working on the proposal. Thanks for taking the time to review it!
Cheers Bang
On Sun, Mar 30, 2014 at 6:00 AM, Damian Johnson atagar@torproject.orgwrote:
Just updated a new revision of my proposal on melange. Looking forward
to
more feedback on how I can improve it and what direction I should
approach
this project!!
Hi Bang. Thanks, this is certainly an improvement! However, I think there's some confusion about the present state of arm...
The main bulk of the work would be to port Arm's functionality away
from TorCtl.
Arm's development codebase has already been ported from TorCtl to Stem. It's a bit of a mess right now from the overhaul, but functional...
https://gitweb.torproject.org/arm.git
First would be to design the user onboarding flow - how the user gets
from selecting a certain configuration to managing the views.
I'm not sure what you mean in this paragraph.
The reasons for choosing the micro web framework is because it is
lightweight and flexible and fulfills the basic needs required to make this web relay dashboard work.
Sounds good.
19 May - 25 May - Initial Architecture of Relay Web Status Dashboard,
Discussion and review with mentor
Actually, this is what I'm hoping for the proposal to cover. ;)
26 May - 8 Jun - Porting of Arm modules from TorCtl to Stem
Again, this is already done.
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
On 4/1/14, 10:56 AM, Damian Johnson wrote:
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?
In TBB 3.6b1 on Mac OS, tor has been renamed to tor.real and tor is a shell script that execs tor.real. See: https://trac.torproject.org/projects/tor/ticket/10030#comment:20
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.
Thanks for the feedback! The scope of this project is much clearer to me now. I have made changes to the proposal based on this. Sorry my updates have been slow because i'm swamped with school work atm.
In TBB 3.6b1 on Mac OS, tor has been renamed to tor.real and tor is a
shell script that execs tor.real. See:
Ah I see, thanks for the clarification!
On Tue, Apr 1, 2014 at 11:13 PM, Mark Smith mcs@pearlcrescent.com wrote:
On 4/1/14, 10:56 AM, Damian Johnson wrote:
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?
In TBB 3.6b1 on Mac OS, tor has been renamed to tor.real and tor is a shell script that execs tor.real. See: https://trac.torproject.org/projects/tor/ticket/10030#comment:20
-- Mark Smith Pearl Crescent http://pearlcrescent.com/
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Bang Hui Lim -
Damian Johnson -
Mark Smith