On Sat, May 17, 2014 at 04:06:52PM -0500, Larry Evans wrote:
The way I read Bjorn's statement:
I am not against a higher level actor API, but the fundamentals need to be in place first.
is that Bjorn's not objecting to a high level of abstraction; however, he wants a lower level first on which to build the higher level. IOW, he's not saying, as you suggest:
to not having an actor library in Boost
At least that's the way I read his post, FWIW.
Fair enough. I'm not subjecting the idea of having buiding blocks generalized to allow others to build on top of it. I hope my response didn't sound disrespectful. Still, I don't think active objects are building blocks for actors, they're a different kind of abstraction. Bjorn also mentioned data flow as building block. You can see the messages going through an actor system as some kind of dataflow, but there are no streams. This is about message oriented programming, not about streams and dataflows. It's a different paradigm. The middleman operates on messages and (logical) actor addresses, not on data flows. I don't know if the middleman implementation has parts that are worth separating. It (1) manages connections (you can do that with Asio already), (2) dispatches messages based on logical actor addresses, (3) manages proxy instances for remote actors, and (4) keeps a lookup table for type IDs for each connection it has; this is only an optimization though, nothing essential. That's about it. The serialization layer used by the middleman might be useful to others, but it is strongly coupled with uniform_type_info. If there's any interest in lifting this thing to its own library, I have no objections. Please let's take the discussion to a different level. With this preliminary submission, I wanted to get a feeling if there is interest in a Boost.Actor library and if it can get enough momentum to eventually find a review manager. I guess this is the question I should have asked in my original post: "Do you think Boost should provide a high-level programming paradigm such as the actor model and if you do, do you think the proposed design is the right one?" I know that this is a large library. The more important it is in my opinion to talk about concepts, API, and possibly documentation. Maybe I'm naive, but separating parts of the library or tweaking implementation details should be the last step, should it not?