Hi Darryl, --- Darryl Green <darryl.green@myrealbox.com> wrote: <snip>
I would like to see fine-grained composition from policies similar to the concepts just to make it easier to maintain and extend the lib (or maybe more the other way around ;-).
None of the above implies any major change of design, rather it takes advantage of the design to offer adaptability and portability without limiting either. I think it would be unfortunate if forms of IO that are not 100% portable were excluded from "first class" status in the library. Encouraging the utilization of the design's strengths by making it easy to re-use and extend the library can only encourage its acceptance and wider use and development. This would perhaps require some refactoring of the services and documenting/exposing some of the detail, but not much else.
What do you think?
I do appreciate where you're coming from, but I think we must have fundamentally different design philosophies in mind. To summarise my understanding of it, you want to be able to leverage commonality of implementation on the platforms that you target, and compose policies to influence how the abstractions, such as stream_socket, behave. With asio, the public interface instead says nothing about commonality of implementation, since such commonality cannot be portably assumed. The implementation detail can make use of such commonality, certainly. For the user of asio, commonality is provided through implementation of concepts, such as the Stream concept implemented by stream_socket and ssl::stream. I am not averse to compile time or runtime tweaks to alter implementation behaviour. Or, dare I say, completely different implementations of the public interface that provide alternative QoS characteristics. But ultimately I am not in favour of the sort of framework that allows endlessly customisable behaviour via policy composition for a library such as this. Of the programmers developing networking code, I imagine that very few have both the skills and inclination to make use of this level of customisation in source code. Besides, the more combinations, the greater the chance of something going wrong, and the less time I can spend testing each one! The number of permutations allowed by such a policy-driven interface would be a barrier to what I believe is a more important goal: the development of portable, reusable, higher-level abstractions. Cheers, Chris