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