Re: [tor-bugs] #9668 [Flashproxy]: restructure flashproxy source tree

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

#9668: restructure flashproxy source tree
----------------------------+-----------------
     Reporter:  infinity0   |      Owner:  dcf
         Type:  defect      |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+-----------------

Comment (by infinity0):

 I am going to package everything, and my current thinking (very fluid atm)
 is to have two binary packages:

 - flashproxy-client - client transport plugin plus registration methods,
 so either similar to, or the same as, the currently-distributed tarball
 - flashproxy-server - server transport plugin, facilitator, plus browser
 proxy, in the same package just to simplify things

 "modules" is vague and ambiguous; if you don't want deep nesting, how
 about renaming this to "proxy-modules"?

 WRT flashproxy-client being a "second-class citizen", well everything else
 is already a "second-class citizen". My main concern is that the top-level
 Makefile/setup.py has a bit of an identity crisis. Currently they build
 the client/client-reg code but Makefile also tries to be a parent for
 other things, such as running facilitator/proxy tests.

 Either it should *only* be responsible for the client, or it should *only*
 act as an aggregator for other sub-components. (And it's important to have
 some sort of aggregator to make it easy to "build/dist/test everything".)
 I don't see a way to resolve this, other than by nesting the client -
 since if the build scripts are top-level then the temptation will always
 be there to use it to aggregate other things from subdirectories.

 Why keep client stuff at top-level? We can retain a way to make a client-
 only tarball, if that is your main concern.

 (I'm also thinking through the idea of a naming convention like tor-pt-
 flashproxy, tor-pt-websocket, but that is another concern; I've brought
 this up on the tor-dev mailing list.)

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