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