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