Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 10:15:36

"Christopher Kohlhoff" <chris_at_[hidden]> wrote

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

Than have you considered putting them in a type rather than in an object?  I
mean defining them as static functions inside a class, and then providing
the typedef to this class as a part of your configuration, depending on the
platform used?  This is better than singleton, since your library could
remain header-only.

I realise that would not work for demuxer (demultiplexer?), but I am still
thinking this is not the best idea to mix it with the platform traits.

> > 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.

See, this doesn't look intuitive to me.   I am by no means a networking
expert, but I have done some work with sockets.  And, IMO, a socket doesn't
have to do anything with being asynchronous-enabled or not.  Asynchronity is
about how the socket is used, not about the socket itself.

If you split demuxer from platform traits, and free the socket
implementation from the asynchronisity, moving it outside, than all the
socket needs to know about is platform traits.  This could be used as I
suggested above (through the typedef), and your socket constructor would not
have to accept any parameters at all.

> > 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.

Well, personally, I would still like to see a nice socket API, as a part of
any networking library accepted into Boost.  And I think it should be
closely mapped (conceptually) to existing socket APIs, such as Berkeley,
winsock, etc., maybe Java sockets.

The rest of the library, which implements higher-level abstractions (such as
demuxer), could depend on this layer, but not visa-versa.

Regards,
Arkadiy