[tor-bugs] #4257 [Torctl]: Stem / TorCtl Integration

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Wed Nov 9 16:11:41 UTC 2011


#4257: Stem / TorCtl Integration
-------------------------+--------------------------------------------------
 Reporter:  atagar       |          Owner:  mikeperry   
     Type:  enhancement  |         Status:  needs_review
 Priority:  normal       |      Milestone:              
Component:  Torctl       |        Version:              
 Keywords:               |         Parent:              
   Points:               |   Actualpoints:              
-------------------------+--------------------------------------------------

Comment(by atagar):

 > What should I do with this?

 That depends on how we want TorCtl and stem to be related. As I see it
 there's a couple options...

 * Option 1: Incrementally replace TorCtl's implementation with calls to
 stem. That is what this change is for.

 advantages:
 - the migration will be transparent to TorCtl users
 - TorCtl will begin to have testing for its core functionality
 - changes are gradual so if there's any compatibility issues then they
 will be easier to catch

 disadvantages:
 - this requires active involvement by both me and the TorCtl maintainer
 - we don't have any testing for TorCtl or its users (though I'd still
 argue that a series of small changes will be less painful than a single
 huge one)
 - if this collects dust for months then it'll become unreasonable to
 continue with this approach

 * Option 2: Big bang migrations later. In this case I'd ignore TorCtl for
 now, finish stem, then either help to rewrite TorCtl users or make a
 TorCtl facade. I'm not sure if it's an advantage or disadvantage, but stem
 would be a proper fork of TorCtl so users could opt to use either.

 advantages:
 - no up front involvement by either of us
 - narrows the window where dependencies change
 - for better or worse TorCtl's codebase never changes

 disadvantages:
 - TorCtl doesn't get any benefit from stem
 - big bang migrations are more painful for users
 - compatibility issues are harder to track down

 > or should I just be reviewing it for API sanity?

 I'll let you know when it's ready for a review. At present just the socket
 listening and message parsing components are complete. At this point the
 user facing functionality would be easy to write, but my focus is on
 shoring up the utilities and testing first.

 Cheers! -Damian

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4257#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list