Boost logo

Boost :

From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-01-03 08:46:56


Christopher Kohlhoff wrote:
> 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.
>

Hum, I think that asio should guarantee to be *implemented* in terms of
this library. Let's say that this library provides a reactor, i would
want that my code and asio use the same instance of that reactor. And
any way, it would be useful to use asio callback dispatching with custom
  strems.

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

I do not agree, in fact it is useful if a library provides two diferent
intefaces: one for end users and one for library developpers/extenders.

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

Well, we are not asking to make the implementation public right now.
This could be done at a latter stage, when the implementation is stable
enough.

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

You are certanly right. Asio does very well what it guarantees it does.
But it would be a pity, if it you didn't extend it a little to do what
it could do with a very small amount of work (this sentence doen't make
much sense. What i mean is that just by exporting the detail interface
asio would become immensely more useful)

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

Well, may be because they don't make sense outside a specific
application, and still benefit from the internal detail of asio.
Reimplementing this details would be a wasteful duplication of code. And
even if a service is not that specific, i don't think that asio can
realistically be a repository of all possible I/O types.

In the end, the final decision is up to you.

HTH

---
Giovanni P. Deretta

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk