search

jacksonh / manos

Manos is an easy to use, easy to test, high performance web application framework that stays out of your way and makes your life ridiculously simple.
Other
454 stars 61 forks source link

Don't pass sockets into HttpServer #110

Open ghost opened 13 years ago

ghost commented 13 years ago

Create them from context instead.

txdv commented 13 years ago

I gave it a thought and passing the socket is a valuable idea.

By passing the sockets you can force HttpServer to use special sockets, for example SslSocket. Since HttpServer uses only Listen, maybe passing it in the constructor is the best way to go.

I was just confused when creating an IrcClient class, because I just went with what I have already seen (socket in the constructor), but the IrcClient doesn't listen on any port, actually it has to connect to various other sources and recreate the socket if the connection fails or can't be completed.

But still, IrcClients can use ssl and socks4 to communicate: in order to use different functionality, i need to provide the socket in the constructor, but on the other hand I can't do, because I have to recreate the socket.

One possible solution to solve this dilema is to make sockets reusable, what do you think myeisha? I can probably come up with some delegate based API, but it would look ugly as far as I can tell.

ghost commented 13 years ago

Yeah, no. The idea behind the current IO architecture was to have simple base functionality, and a pipeline that wraps more and more around it. For SSL, you'd hook into the pipeline at ClientConnected and wrap the stream in a TlsStream.

Same or similar things work for other protocols. In the IRC example, you wouldn't even need that, because the IRC client would be happy with only a stream it can work with. You would then have static factory methods that connect to foreign servers via different transport types.