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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 sisbell):

 Replying to [comment:6 eighthave]:
 > I guess we should also have an automatic naming convention for
 translating ControlPort command names to Java method names.  The existing
 standard is to use camelCase for ControlPort commands with an `_` in them,
 and when there are clear words.  Then camelCase for methods that are not
 just direct calls for ControlPort commands.  For example:
 >
 > * `takeOwnership()` -> `TAKEOWNERSHIP`
 > * `setEvents()` -> `SETEVENTS`
 > * `addOnion()` -> `ADD_ONION`
 > * `dropGuards()` -> `DROPGUARDS`
 > * `resetConf()` -> `RESETCONF`
 > * `hsFetch()` -> `HSFETCH`
 > * `hsForget()` -> `HSFORGET`
 > * `sendAndWaitForResponse()`
 >
 > So @sisbell's proposal looks good to me, except `takeownership()` should
 be `takeOwnership()`.
 >
 > I can put together this update for the things that I'm proposing, as
 long as Tor Project is willing to use it and make the releases to Maven
 Central.

 This makes sense on the naming conventions. There are a lot of possible
 commands. We can probably just start with those we need for Orbot/tor-
 android-service. Any additional ones from the community can be opened as
 tickets. If we have the ability to control the code. I'd suggest a base
 classes which just the connection stuff and then drop all the tor specific
 commands to a subclass, just to make the code a little more readable.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs