Boost logo

Boost :

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-31 08:57:49

Christopher Kohlhoff wrote:
> 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.

I don't want to change the behavior of anything. I want to map some
concepts into policies, properly define them and have lots of impls all
with the same behavior. I see that you didn't respond to any of my
specific examples of other I/O channels or the breakdown of "what I
would like to see". Do you intend to implement every form of I/O,
including message-based and stream-based IPC, disk, character devices
and the ever-growing plethora of networking protocols (I see someone
else has mentioned SCTP already) that can be done asynchronously? I
realize that it would be unusual for anyone to need all of them, but
someone needs each of them - I was hoping that the library could be
opened up to those someones to extend without creating a maintenance

> With asio, the public interface instead says nothing about
> commonality of implementation, since such commonality cannot be
> portably assumed.

Fine. I'm not suggesting you can or should require it - I am suggesting
that if the design was tweaked slightly, it would be possible for the
user/extender (or the maintainer/author) to re-use impl when it can be

> 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.

Yes. I want to make public impls of the concepts in a more flexible way.

> 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.

Huh? I'm utterly confused. I guess you must be too - sorry I'm obviously
doing such an atrocious job of describing what I'm after. I split up my
replies to try to focus the discussion better and avoid confusion but
obviously I've failed.

> 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

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.

> 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 testing and maintenance angle is one of my major motivations for
proposing this. If you have umpteen different forms of I/O all of which
use the same readiness notification mechanism and require the same
processing to actually do an async read/write why would you want to
implement and maintain and test umpteen separate user accessible
services for read/write rather than testing that your shared read/write
impl in depth and the aspects of those various forms of I/O that are
unique such as the way that the channel is opened separately?

I'm guessing that you wouldn't actually chose to duplicate code and you
would use shared code in detail to avoid it. 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. If nothing else this makes the testing scale better
without having tests rely on non-public interfaces.

The other aspect of testing is that nobody can be expected to test code
that isn't in the lib - if a user extends the library and either doesn't
contribute the code or it isn't accepted into the lib there is nothing
extra to test? 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.

> 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.

I see the ability to adapt the library while preserving a consistent
interface to be a necessity to support higher-level abstractions.


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005

Boost list run by bdawes at, gregod at, cpdaniel at, john at