Re: [boost] asio formal review - portability

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