Don't pass sockets into HttpServer

[ghost]

Create them from context instead.

[txdv]

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]

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.