Re: [boost] asio formal review - portability

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-03 07:20:20

Hi Darryl,

> If the library just magically supports every form of IO on a
> platform out of the box, with the choice of I/O mechanism
> being largely transparent to higher-level code, then there
> will be no need for customization. I don't think that is a
> realistic requirement.

Here I think you have identified precisely what I intend asio to
be in the longer term. It is what I mean when I say that a goal
of asio is to take a toolkit, rather than framework, approach.

Asio is intended for the development of applications that need
to use the I/O services of their target platforms in an
efficient and scalable way, without:

- having to be aware of the details (or even the existence) of
  demultiplexing

- needing to worry about platform differences.

Asio is a codification of experience with demultiplexing and
low-level networking APIs. It should provide an interface that
requires none of this knowledge.

I think it is realistic and, more importantly, widely beneficial
for this experience to be captured and presented as a library.
It is unrealistic to expect most projects to require their
developers to learn all of these I/O mechanisms to the level of
detail required to use them effectively.

> I'm suggesting that with care the shared code can align with
> concepts/policies and, once it is (meaning it has a defined
> interface and semantics) it can be made public. Thats all.

So what it seems you want (and I hope I am now understanding you
correctly) is access to asio's implementation details through a
public interface, so that you may use them to develop your own
I/O mechanisms.

Let's review what I see as asio's level of abstraction:

    high level networking
  application frameworks and
    protocol abstractions
           \  |  /
            \ | /
             \|/
         asio toolkit
             /|\
            / | \
           /  |  \
    platform-specific and
  restricted portability APIs
  and demultiplexing methods

I have said on previous occasions that I would be happy to see
asio's implementation details evolve into a secondary public
interface. I recently realised that it would be more appropriate
as a separate library. This library would package I/O mechanisms
at the lower level of abstraction. It would be targeted at
developers who require the lower level of abstraction.

Asio could potentially be implemented in terms of this library,
but this library is not asio.

I believe it is important for a library to have all its public
interfaces at the same level of abstraction. This better defines
the intended scope and uses of the library.

To have a library encompass multiple levels of abstraction would
lead to tension in trying to support different audiences with
differing needs. By making current implementation details part
of the library's interface contract, you either restrict the
ability to refactor the implementation, or risk creating
orphaned interface elements.

During the review, some people indicated a desire for lower
level APIs, just as others requested higher level networking
abstractions. There is nothing wrong with asking for a level of
abstraction that asio does not provide.

Naturally, it is not sensible to say that a library provides the
wrong level of abstraction. The abstraction level is only wrong
in the context of a use case. If an application requires a
different level of abstraction, then asio may not be the
appropriate tool.

> I'm not asking for a lot of weird mix-and-match policies -
> just a few to compose the sorts of services that the lib
> should (imho) support anyway, but in a user configurable way.

But if your ultimate need is an implementation of specific I/O
services (for example, pipes or UNIX domain sockets), why must
they be implemented outside of asio? I agree they should be
supported, so please, contribute them to the toolkit or assist
in their development. Others will benefit from your expertise,
just as reciprocally you may benefit from the expertise of
others as captured in asio.

Cheers,
Chris