Arkadiy Vertleyb wrote:
"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote
The key problem with that approach is that a `thin' wrapper over the platform APIs is basically useless for implementing asynchronous operations, because asynchronous operations must be implemented in widely different ways on the different platforms.
For synchronous operations, it happens to be the case that every platform provides basically the same interface, so at least a portable (but not necessarily very good) interface can be created through only a thin wrapper.
Then maybe it would make sence to define this kind of API for synchronous operations, while asio encapsulates asynchronous IO using a higher-level abstraction. The socket class would be cleanned from the asynchronous stuff, and used by both asio and synchronous API.
For me a 'socket class' is two things (let's ignore datagram sockets in this context): a way to create socket endpoints, as well as manipulate associated options, and on the other hand some means to read and write. For the synchronous case I think this is nicely described by a streambuf / stream pair of interfaces. A 'socket_stream' class would allow to create socket endpoints, and set socket options. A socketbuf class would implement read and write operations. I'm not sure what Jody would want to do with sockets that can't be represented by these two. On the other hand, asynchronous I/O over sockets would be handled very differently. In fact, given that platforms provide quite different means to wait for readable data (say), I'm not even sure that the 'socket' concept should be discussed independently from the sync / async policy at all. Regards, Stefan