Andrew,
working on something else (ibverbs Infiband support) that will force me to abstract monitorable things (fds on Unix) away from Sockets or whatever else sits on top of them.
I thought about this for a while, so let me propose this counterexample. It seems that there are currently two active or proposed transport mechanisms: TCP and Infiniband. TCP can either be regular Sockets, or SSL Sockets, but it's the same transmission protocol. Infiniband is a different beast entirely. That's why I thought it would be a good idea to add the SSL functionality to the Sockets class instead of making a SSLSockets class. If, for example we desired to support more protocols like Infiniband, IPX (Netware), and TCP, I could see further extracting the interface layer to include SocketsIP, SocketsIP_SSL, SocketsIPX, and Infiniband.
Adding to the Sockets class is also desireable in the interest of the least amount of code modification in other places. For example: When you request a Socket, just tell it in the beginning if it's SSL or not and give it the required info, and then once it's running you use it like any other Socket. During reads, writes, polls, etc. the code shouldn't care if a particular Socket is SSL or not.
But, as I haven't done an exhaustive code review yet, I don't know if my analogies apply to this codebase. Am I off base here?
Thanks, -Josh
