|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk