From: Yigong Liu (yigongliu_at_[hidden])
Date: 2006-02-28 02:45:08
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