Re: [boost] asio formal review begins

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-14 22:41:43

"Ben Artin" <macdev_at_[hidden]> wrote

>  "Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote:
>
> > "Eugene Alterman" <eugalt_at_[hidden]> wrote
> >
> > > There is nothing special about synchronous operations, and they have
> > > been implemented in similar ways in dozens of networking libraries.
> >
> > See, I don't care much about other libraries -- I am not going to use
them.
> > But if this one becomes part of Boost, I may start using it, and so I
would
> > like it to have what I need, with a clean interface, and implemented in
a
> > clean way.
>
> IMO this is completely beside the point. This is not the boost networking
> library, it's the boost async IO library, and as such whether it supports
sync
> IO or not is completely irrelevant.

When I was reading through the library tutorial half of examples there were
related to the synchronous IO.  And, in all these examples a demuxer object
was used, that has nothing to do with synchronous IO.  Do you think this is
a clean interface?  Do you think having to create and pass around an object,
that is conceptially not required, is irrelevant?

If the library doesn't want to support synchronous IO this is fine, but
since it does support it, how it is supported becomes relevant.

> There are really two possibilities here:
>
> 1) You may some day use an async IO library, in which case this library
will be
> useful to you and you should review it for its merit with regards to its
stated
> design intent or
> 2) You will never use an async IO library, in which case this library will
never
> be useful to you, and you should still review it for its merit with
regards to
> its stated design intent, while acknowledging that it does not necessarily
fit
> your problem domain.

I was under impression that I am reviewing it right now :-)

There is a third possibility, which IMO is more probable, that I will want
to use some combination os sync and async features.  That's why I would like
to see them nicely fit together.

> However, right now you seem to saying that you are not interested in async
IO,
> and that this library, whose stated intent is to provide async IO, is
therefore
> unacceptable to you.

This is a total mis-interpretation of what I have been saying.

> You have a nail. This library is not a hammer.
>
> IMO, if you want a clean synchronous IO API, you should not be looking for
it in
> an async IO library.

If the lirary has the support for synchronous IO API, it should be clean.
Either have a clean support or no support at all.

Regards,
Arkadiy