Re: [tor-bugs] #9975 [Flashproxy]: use argparse rather than getopt

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

#9975: use argparse rather than getopt
-----------------------------+--------------------------
     Reporter:  infinity0    |      Owner:  infinity0
         Type:  enhancement  |     Status:  needs_review
     Priority:  minor        |  Milestone:
    Component:  Flashproxy   |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by infinity0):

 Here's another try. I've rebased everything on top of current master,
 since it's been a long time since the original fork:

 https://github.com/infinity0/flashproxy/compare/master...bug9975_rebase

 The bottom 4 commits
 [https://github.com/infinity0/flashproxy/compare/2d1fd22d^...d3dbe189
 2d1fd22d...d3dbe189] correspond to the ones you approved above. The next
 commit [https://github.com/infinity0/flashproxy/compare/e6b07f1d e6b07f1d]
 is a minor fix on top. (In the previous branch, this fix was incorporated
 into a different commit.) I will straight-up merge these 5 commits to
 master in a few days, but I thought I'd give you some time in case you
 want to have a look at it again.

 The next commit [https://github.com/infinity0/flashproxy/commit/badb39f9
 badb39f9] corresponds to
 [https://github.com/infinity0/flashproxy/commit/31913a47 31913a47] in the
 previous branch, and is possibly controversial. IMO it's a significant
 refactoring gain - 177 ins, 338 del. I've avoided localising the global
 options variables in flashproxy-client, as you suggested. However, for the
 reg-methods, it turns out that this localising is redundant - the
 refactoring already pushes these into the flashproxy.{reg,keys,utils}
 modules. The end-result is that (in each reg-method program) we have a
 global options object initialised after cmdline-parsing, instead of a
 global options class initialised after program load. (I've also avoided
 pushing everything into main()s, to make the diff a bit shorter.)

 I have a few other ways for doing `ignore_pubkey`. Part of the difficulty
 is that inherently the http reg-method is an exception - we're not doing
 an encrypted registration. Here are my preferences:

 1. Treat reg-http as an even more special anomaly, and just verbosely copy
 the other flag-parsing code from flashproxy.reg. This would make the
 shared code nicer, its interface nicer for future reg-method authors, but
 it would make reg-http look worse.
 2. Keep ignore_pubkey in the code, but instead of ignoring the flag, just
 disable it altogether. This makes things nicer for the user, but it means
 flashproxy-client can't unconditionally pass --facilitator-pubkey to the
 reg-methods.
 3. Take ignore_pubkey out of the code, and have *every other* reg-method
 have to explicitly parse --facilitator-pubkey.

 Actually, I like (1) the more I think about it, so I will probably go and
 implement that. Perhaps I'll even keep the ignore-pubkey behaviour (inside
 reg-http only), since it lets flashproxy-client unconditionally pass the
 flag to any reg-method.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9975#comment:16>
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