Re: [boost] asio formal review begins

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-12-14 17:31:22

Arkadiy Vertleyb wrote:
> "Jeremy Maitin-Shepard" <jbms_at_[hidden]> 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