On Thu, Sep 6, 2012 at 5:30 PM, Joachim Bauch <j...@struktur.de> wrote: > -----Ursprüngliche Nachricht----- > Von: Nick Mathewson <ni...@freehaven.net> > [...] >> Sounds like a big but fun project. You might want to look at >> bufferevent_sock.c first; bufferevent_openssl.c has to jump through a >> lot of annoying hoops because the TLS protocol has a property that >> doing a read at the TLS abstraction may require a write on the >> underlying stream, and vice versa. If your protocol doesn't have that >> feature, you can get much, much simpler than something based on >> bufferevent_openssl.c. > > Thanks for the heads up. The socket-based code surely will be helpful > when the implementation starts. I wrote an initial draft of how the > API could look like and put it on github: > https://github.com/fancycode/Libevent/blob/bufferevent_indirect/include/event2/bufferevent_indirect.h > > Any feedback is very welcome!
Having new *connect_hostname commands is making me think that maybe this should be an abstract method of bufferevent that only some bufferevent subtypes support. I'd like a better distinction between functions that should be called by the implementation, and functions that exist to be called by the users of this type. Right now I am pretty sure which are which, but only pretty sure. It could be cool to have a way to version the API. I'm also with Mark Ellzey in that I'd like to see a quick example of how this would get used (that is to say, a little example module). *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.