Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-13 16:58:50

"Christopher Kohlhoff" <chris_at_[hidden]> wrote

> --- Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> > Now that I spent some time reading through you tutorial I have
> > a question -- what exactly is the demuxer object?  At first I
> > thought that it somehow relates to the "demultiplexer"
> > pattern.  However, considering a simple TCP client, which just
> > connects to the server, sends a request, and then reads the
> > response, I don't see how demultiplexer is related here.  If I
> > write a similar program using winsock, I can't see anything
> > analogous...
>
> As Eugene said it does act as a sort of service repository. In
> the past I have considered splitting them into two separate
> objects, however opted not to because I felt it impacted
> negatively on usability. Your typical user doesn't want to know
> about the services (see the many requests for me to split the
> reference documentation into two parts so that the services and
> basic_* templates are not intrusive).
>
> Therefore I prefer to talk about the demuxer as a multi-faceted
> object, not completely unlike std::locale. Its primary facet
> (i.e. the one accessible via asio::demuxer) is the one that
> everybody must use if they are going to do any asynchronous
> operations at all, regardless of whether they use sockets,
> timers or something else.

Can your faucets change at runtime?

> As for why the sockets must take the demuxer object even if you
> are just doing synchronous operations... I mean you could have a
> socket implementation that excluded the asynchronous operations,

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

> and a demuxer wouldn't be required in that case. But ultimately
> this library is about asynchronous I/O.

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.

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.

Regards,
Arkadiy