Boost logo

Boost :

Subject: Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
From: Dominik Charousset (dominik.charousset_at_[hidden])
Date: 2014-05-18 02:46:49


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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk