[boost] Re: [Threads] Reactive Objects

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-03-02 21:31:53

Jeff Garland <jeff <at> crystalclearsoftware.com> writes:

> > A reasonable first take on my library is that it implements the
> > ActiveObject pattern. It allows software objects to be implemented
> > that can exchange messages asynchronously
> >
> > Message forwarding and proxy machines allow the software objects
> > involved in an exchange of messages to be distributed over separate
> > processes and machines.
> 
> Ok.  Well there is obviously some sort of networking infrastructure including
> a event dispatching as well.  Again, these are items that are needed in boost,
> have had prior work (in the sandbox), but aren't ready for primetime yet.

This in particular seems to be a big stretch of scope.  I think it would be 
brave to try to put network-transparent messaging into boost.threads, without
first going through an inter-thread messaging stage.

The network-related code in the sandbox does look promising, even if it hasn't
had much obvious development in recent times.  Getting networking into boost
as a subset of an object communication library would seem to be putting the
cart before the horse, given the general applicability of networking code.

Anyone care to comment on the general status of the network code in the 
sandbox?

> The bottom line for me is that your 'library' seems like alot of libraries
> that are tightly stitched together with a fairly narrow scope. I suspect they
> would be very difficult to boostify since they can't be pulled apart easily. 
> Not saying that it isn't a useful framework and I'm not trying to discourage
> you, but at first blush it doesn't seem like a good fit with Boost 'out of the
> box'.  I for one am much more interested in minimalist components that can be
> put together flexably into larger components b/c most of the 'all-in-one'
> frameworks usually are problematic to integrate into larger solutions.

Well, if the layers of the larger library are cleanly separated, the parts
that deal specifically with threads, and with inter-context messaging should
be fairly independent of the state machines, code generators and message
objects layered on top of them?

> Anyway, I'm still interested in a basic Active Object on top of the thread
> library 

What aspect are you interested in?  The pattern, as per Schmidt?  I don't
think there's a lot of detail in that, it would be interesting to know what
boost could offer.  

Otherwise, Scott and I have been discussing interactions based purely on 
message passing between objects, utilising a separation between 'servant'
and 'scheduler' that is reminiscent of the active object pattern (also, the
guarantee of only one thread active in a single object's bounds is similar). 
Is this more like what you're interested in?

Matt