Discuss feasibility of a Python obfsproxy
The first step in evaluating feasibility of a Python obfsproxy could be to discuss possible issues and advantages as compared to the C obfsproxy. Here is a random collection of arguments that I heard from talking to people and which might help kick off the discussion:
-
Maintaining two versions ob obfsproxy is madness.
-
Once we have a working Python obfsproxy we can drop the C obfsproxy.
-
Python will make it easier to keep a sane software architecture than C, in particular when adding lots of transports.
-
Implementing the same transport in C and Python in a compatible way might be difficult.
-
Packaging a Python obfsproxy would be much harder than packaging the C obfsproxy.
-
A Python obfsproxy might not be able to handle potentially large numbers of connections, as opposed to a C obfsproxy.
-
A Python obfsproxy can start as a by-product of working on transports.
There are quite a few people who I've heard might be interested in this topic and who I'm cc'ing: nickm, asn, aagbsn, blanu, zwol, xmux. If more people are interested, please cc yourself.
How about we keep this discussion in this ticket to collect more arguments and figure out which issues and advantages are most relevant?
Should we define a date when we hope to have discussion results? How about April 30?
Who can moderate this discussion and summarize results at the end?