Thanks for the comments and suggestions. I'l definitely look into Boost.Asioand try to build on top of existing boost facilities as much as possible. a. Pub-sub (as you've already mentioned) - is this based
on an existing pub-sub spec or API? (E.g. DDS or JMS) There should be a good justification for providing yet another pub-sub model (versus basing it on something like DDS).
The design ideas of Channel is based on my own experience with message passing/event dispatching systems. I worked on switches/routers control software and distributed enterprise applications; and designed and implemented proprietary messaging systems. The design of these systems include the common set of core design aspects. Channel intendes to be a framework to allow users plug and play, mix and match different parts of messaging systems such as message type or id, routing algorithms, connection transport, etc. to create a best-fit messaging system for a particular application. And it intends to be as easy to use as specializing STL containers. It is not intended to implement an existing standard. b. Distributed state / data store (as provided by the
library or framework, not by an external database). d. Fault-tolerant aspects. (I'll be happy to write more details, if needed.)
During my work on telecom backbone switches, i have experience implementing data replication and high availability control software. These are really important issues. However again, Channel is intended to be a framework of basic, core primitives for programmers to configure a messaging/event facility for his applications. In my experience, high availability and fault tolerance are built on top of messaging (such as heart-beat) and data replication. So Channel is not intended to include all of these inside. Thanks again. Yigong