From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 18:17:00
"Stefan Seefeld" <seefeld_at_[hidden]> wrote in message
news:43A09D3A.2030908_at_sympatico.ca...
> 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.
So, this right away leads you to sync_socket and async_socket. What if the
read/write operations (ones that make the distinctinction between
sync/async) were factored out? Then you would have a socket class to create
socket endpoints and manipulate
associated options, and (a)synchronicity would be defined by the operations
applied to this socket.
Regards,
Arkadiy