Re: [boost] asio formal review - portability

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-30 00:08:12

Hi Darryl,

--- Darryl Green <darryl.green_at_[hidden]> 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