[tor-dev] Comments on librarifying an Extended ORPort client?

[George Kadianakis]

Hi Nick,

I have a question for you. It's not high priority, so feel free to
postpone your answer till after the workshop is over.

Are you aware of pyptlib? It is a small Python library that does the
managed proxy environment-variable/stdout configuration dance, so that
people who write pluggable transports don't have to care how the
pluggable transport protocol actually works.

Another thing I would like transport authors to never learn about is
the Extended ORPort. It would be truly great if pyptlib could do the
Extended ORPort dance (authentication, send client's IP address, etc.),
and after it's completed, let the transport send whatever ORPort data
it wants.

Unfortunately, I don't know how to do such a thing without influencing
a certain networking programming style to the transport author. For
example, if I coded the Extended ORPort client in Twisted, the
transport author would probably have to use Twisted for the rest of
her communication with the Extended ORPort. Similarly, if I coded the
Extended ORPort client using the low-level 'socket' module, a
transport author who wanted to use Twisted would be in trouble.

As a matter of fact, I'm not sure how to do this task without coding
separate different Extended ORPort clients for each networking library
(one for Twisted, one for 'socket', etc.). But this sounds like too
much work.

Do you think there is a way to do what I want, or is it a lost cause?
#7903 is the relevant ticket.

Thanks!