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