Re: [boost] asio formal review begins

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-14 03:33:53

Hi Arkadiy,

--- Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> Can your faucets change at runtime?

No.

> Why is the ability to perform asynchronous operations a
> property of socket?

I chose to make asynchronous operations part of asio's socket
interfaces because, in my opinion, having them there offers the
best ease of use and gives maximum flexibility to provide
efficient implementations portably.

> I can see some contradiction here, since you tutorial provides
> a number of syncronous examples.  Using the demuxer object in
> such contexts seems to be a conceptual overhead, and somewhat
> misleading.

With this tutorial, I was trying to demonstrate the library's
concepts in stages, where each subsequent tutorial introduces
something new. I think it's important that, as you move through
the tutorial, you can see how the synchronous is mapped to the
asynchronous. So the early examples simply don't use all of the
functionality that's on offer. They still have to initialise the
objects correctly according to the library's interface though.

> Also, your library provides some socket API, and therefore, if
> it is accepted, I don't expect any other socket class in Boost
> in the nearest future, which means I would expect your classes
> to nicely wrap all of sockets, not only acynchronos ones.

I've been thinking about these issues since your email. My
feeling is that a use case doesn't have to become very
complicated for the asynchronous operations to be beneficial.
But where a developer's needs are simple enough, I suspect
that's also when they are going to want to use an
iostreams-based interface. Since iostreams basically enforce
synchronous operation, this seems like a sensible place to hide
the demuxer and asynchronicity away.

Cheers,
Chris