Re: [boost] [Threads] Reactive Objects

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-03-01 22:13:58

On Tue, 2 Mar 2004 11:49:50 +1300, scott wrote 
> I have been working on a small library that has become
> reasonably useful and possibly of interest to someone else.
> It's also become fairly large.
>
> I am quite interested in this library getting "boosted" but
> even given that there is substance to the library its scope
> is a bit of a problem; its quite large. It was started as

In general, large libraries are a problem in boost -- for lots of reasons. 
I'd encourage you to break things down into useable pieces and focus on
getting the most useful parts boostified.  If it is really large, it will be a
long road...

> ...snip....
> A breakdown of the incidental technologies tackled by
> this library follows;
> 
> * multi-threading building block classes

Yes, you'all have been discussing some interesting possible extensions for AO
and such.  Sorry I haven't been able to keep up with all of it.  Anyway, these
would be a nice contribution in my view.

> * network representation of structured data (variants)

How different from boost.Variant?

> * saving and loading of network data (persistence)

Robert Ramey has done a huge amount of work on this -- have you checked it
out?  This library has been through one review cycle and I believe Robert has
now addressed all the big concerns.  My sense is that his library is the 'one'
for persistence.

> * interactive machines (inter-thread messaging)

Another needed extension of boost.threads all would agree.

> * stateless and stateful machine representation

How does this contrast with the boost.fsm (finite state machine)
implementation in the boost-sandbox by Andreas Huber?  I think the project has
been dormant for awhile although I notice the docs page was update in Feb
2004.  Anyway, it is quite interesting.

> * code generation of network data and machine skeletons

Not sure this would really be appropriate for a boost library...

> * message forwarding (distributed messaging)
> * transparent remote machines (proxies for inter-process messaging)

Are you talking about multi-cast messaging, publish-subscribe, method
invocation, or what?

> * support for multiple encodings, e.g. binary, text, XML...

Also covered by the persistence library.

>...snip example...
>
> I am very happy to work towards a boosted version of a subset of
> this work cos basically it seems too large to be a prospect

Agree.

> otherwise. This subset would be in the area of mutli-threading
> building block classes, i.e. an "alternate threading model". However,
> after the recent exchange of related and interesting messages, I felt
> compelled to "come clean" with some background.

Hmm, hope I'm not jumping in in the middle without context.  In any case, I'm
agreeing with the need to focus.

Jeff