[tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-------------------------------------------------+-------------------------
 Reporter:  eighthave                            |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,        |  Actual Points:
  TorBrowserTeam202001                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by eighthave):

 Replying to [comment:16 sisbell]:
 > Overall looks good. A few clarifications, questions.
 >
 >  1. From an API perspective, the distinction between rawEventListeners
 and the EventHandlers isn't obvious. Why is one called handler and the
 other is called listener? What is the different? Should we use consistent
 terms?

 I think the EventHandler API should be deprecated since it only allows a
 single instance to be registered, and it introduces its own abstraction
 layer which needs to be separately maintained, and diverges from the
 control-spec docs.  I chose the word "Listener" since as far as I know,
 that's the common name for the Java pattern where you can register
 multiple instances to listen for events.

 >  1. Better to use ArrayList.isEmpty rather than ArrayList.size() == 0
 (!TorControlConnection:221)

 yes, thanks for that.

 >  1. What is the package name we are going with (net.freehaven? or
 org.torproject?)

 I like the idea of switching to org.torproject to mark it as official, but
 I would be OK if people wanted to keep it as net.freehaven.

 >  1. We do have clear SignalType enums, Does it make sense to use these
 for type safety?

 I'm not sure which enums you're referring to, but I agree it does make
 sense to sync any relevant data structures from Tor source code to
 jtorctl.  I think jtorctl should reflect the Tor source code as directly
 as possible, to keep it maintainable and related to the dos.

 > https://www.antlr.org/

 Sounds good to me, I've never worked with parser generators, so I'm just
 guessing here.

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