I have a couple of major concerns with the current submission, and I am going to suggest some substantial changes. I hope that it does not discourage you too much. I am going to suggest that: 1. The library is broken into more fundamental building-blocks (which is what both Boost and the C++ standard is all about.) 2. A more flexible data flow architecture is adopted. 3. More use of existing Boost libraries. I recognize three more fundamental building-blocks in the current submission: active objects, messaging middleware, and data flow. I am not against a higher level actor API, but the fundamentals need to be in place first. Building-blocks --------------- Boost.Actor implements a distributed mailbox-based actor model. While this is a building-block to some users, it is not fundamental. It conflates the actor with distribution. I suggest that you start with a non-distributed actor model. This is simply an active object with an incoming message queue. This can be used its own right without distribution and mailboxes. Many applications have classes with a working thread inside them, and active objects should strive to replace these classes [1]. Active objects have two important variation points: scheduling and the queue type. Regarding scheduling there is a C++ standards proposal that should be considered [2]. There is a GSoC project about this [3]. For the distributed case, boost::asio::io_service also has to be considered. There is also work done on message queues. We already have some in Boost.Lockfree, or the wait-free multi-producer queue in the Boost.Atomic examples, as well as sync_queue in Boost.Thread. Architecture ------------ Once we have got active objects, the question is how do we connect them? The variation points here are routing and transmission. The mailbox approach is too simple for many applications. Partly because it is too limited in some regards (e.g. push-only) and too flexible in other regards (e.g. you cannot have fine-grained access control or restricted visibility.) There are several flow-based approaches that should be considered: Boost.Iostreams has all the required concepts in place. There was a Boost.Dataflow GSoC project [4] some years ago. There is a C++ standards proposal [5] about C++ pipelines. See also the ZeroMQ guide [6] for various examples. Boost.Actor implements its own network protocol, but you often need to integrate with an existing protocol, such as MQTT [7] or DDS [8]. We can add distribution by having proxies. The proxies can hide the details about routing (e.g. actors may change location due to load balancing or migration,) and network protocol. Library reuse ------------- Although Boost.Actor reuses other Boost libraries, it has implemented quite a lot that either exists in other Boost libraries, or that could be moved to those. You have already mentioned that you do not use MPL, Serialization, and Asio, so I will not delve into these, other than saying that I believe that having your own socket implementation instead of using Boost.Asio is a show-stopper. Apart from these three, there are other libraries that should be considered. Boost.Actor has: o Own continuations instead of Boost.Thread (future::then) o Own producer-consumer queue instead of Boost.Lockfree o Own logging framework instead of Boost.Log, although I would prefer not having logging in a library at all. o Own UUID instead of Boost.UUID o Own time duration instead of Boost.Chrono Then there are code that could be refactored to other Boost libraries so they can be used in other contexts. For example: o Stacktrace dumper o RIPEMD hash function o MAC address [1] http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225... [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3785.pdf [3] http://cs.mcgill.ca/~iforbe/ [4] http://www.dancinghacker.com/code/dataflow/index.html [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html [6] http://zguide.zeromq.org/page:all [7] http://mqtt.org/ [8] http://portals.omg.org/dds/