Re: [boost] Any interests in a template library for distributed message passing and event dispatching?

From: Cliff Green (cliffg_at_[hidden])
Date: 2006-02-27 16:13:57

> Is there any interests in libraries for distributed 
>message passing and
> event dispatching? There are many aspects involved in 
>the design of these
> systems ...

Yes, definite interest from me, and I think you'll find a
lot of interest from other developers or organizations.

I assume you have (or will) port from using ACE to using
Asio - unless major problems are found with Asio (and I
don't think the major review from a few months ago found
any), that would be the library to use for the lower-level
socket and demuxing encapsulation. I don't see any need to
duplicate the functionality of Asio inside your own
library or framework (which is a higher-level layer than
Asio).

Besides (and probably in parallel with) the issues you're 
trying to solve, I've written libraries that provided:

1. Incoming and outgoing message filter chaining
(functionality that was just mentioned last week in
relation to Asio, I think). This allows applications or
libraries to easily add functionality such as encryption,
compression, validation, recording, monitoring, or other
application-specific processing.

2. Customizable "message" encapsulation / boundary 
processing, in the sense that every distributed processing 
scheme has a defined protocol that delimits a message. 
E.g. a text stream message might be delimited by a 
new-line, a binary message might have the length encoded 
as the first field, a binary message might be a fixed-size 
"struct", a text protocol such as XML has specific matched 
delimiters, etc.

I'd be very much interested in a higher-level layer that 
solved some of the needs associated with certain kinds of 
distributed processing:

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).

b. Distributed state / data store (as provided by the 
library or framework, not by an external database).

c. Scalability aspects. (I'll be happy to write more 
details, if needed.)

d. Fault-tolerant aspects.  (I'll be happy to write more 
details, if needed.)

I'll catch up with the rest of the Boost e-mail to see if 
other people have written anything similar ...

Cliff