In my experience in attempting to develop an over-general sockets abstraction, it is next to impossible to contrive a perfect generalization of the many different socket types.
A good sockets implementation will at a minimum: * Use polymorphism on a well-defined socket interface. This will allow code to be written that is protocol neutral and easy to maintain. This is also a better choice over attempting to create an overly complex do-all 'socket' class that takes an enum to try and determine the protocol desired--I think everyone will agree that attempting to use GP and Policies will be just as messy here. The implementation will be much cleaner when small, specialized implementations are allowed. This approach will also trivially allow extensibility (even by the boost::end.user) to support other implementations that can be submitted without affecting existing implementations. Also, specific protocols should get their own sub-namespace. * Separate Reading/Writing versus Connecting or Accepting connections. There are a few ways to do this, either by having a pure interface that defines reading or writing and an object (kind of factory?) that will accept connections or create new ones. This seems like a good approach because it distills functionality between the two main needs of sockets. It also may ease development because in general, on a given platform, I/O on a socket is usually identical and not dependent on the protocol, where connecting is. However, this may go against the desired user convention, which needs to be decided over and before any implementation convenience. It may be decided that sockets have a constructor that take an (protocol-specific) address class (implicitly constructible by a char const*) for opening connections, and there is only a listening service type class that takes in new connections and returns a socket that is already connected. * Support for Event-Driven and Blocking sockets This one should go without saying. The event-driven support can trivially be provided in the pure socket interface and easily created using tools like boost::signals or boost::function. ** Thread Pool For event-driven sockets, a thread per socket can sometimes be wasteful, so there may be support for using a thread pool that monitors for events on the sockets in an application. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost