[boost] a new release of Channel framework

From: Yigong Liu (yigongliu_at_[hidden])
Date: 2007-01-15 16:43:36

Hello all,

I just uploaded a new release of Channel framework at
http://channel.sourceforge.net. Channel is a template framework for
asynchronous distributed message passing and event dispatching. Channel is
built on top of many boost facilities. Here are the links:
Design doc:
http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html
Website: http://channel.sourceforge.net
Download: http://sourceforge.net/projects/channel

Changes in this release:

1> complete filter and translator related code.
   When we build distributed applications around distributed name spaces, we
may want to "relocate"/"mount" the names imported (from a connection to a
remote name space) to a specific sub-region in local name space. For
example, if we have a name space in desktop computer and connect to a PDA
and a laptop, we can set translators at connections so that names imported
from PDA will appear under "/pda/" and names from laptop will appear under
"/laptop/". Or if our application use integer as ids/names, we may want to
relocate ids from the 1st connection to [1000-1999] and ids from next
connection to [2000-2999] and so on. That is similar to the way how we mount
remote file-systems to local file-system. filters are used to restrict the
valid range of names allowed to pass in/out specific channel connections.
   A sample is added to demo the usage of filter and translator.

2> add "unnamed" bindings of sender and receiver.
   Up to now, most of efforts focus on setting up the binding between
message senders and receviers thru name-matching in name_space. Often when
we apply message passing / event dispatching model to implement localized
(in a single address space) applications or modules, we may not want the
trouble of setting up name space and assigning names. Many message passing
based systems (such as inferno/limbo, plan9/libthread, CCR, C++CSP) provide
"port" or "channel" (which are normal local objects) to help build these
applications. From Channel's design perspective, these local communication
primitives are special bindings of sender and receiver. They are "unnamed",
not set up thru name-matching in name space. These unnamed primitives can
work with named primitives smoothly. Design document has been updated to
cover this. Sample unnamed primitives have been added and some sample
applications are added to demo the usage.

Suggestions and comments are highly appreciated. More is coming.

Thanks
Yigong