Some immature thoughts on inter-actor communication

[hanekoo]

Thank you very much for your contributions to this project. I have already used it in practical projects, and the asynchronous features have been very helpful.

Here are some thoughts I had while using it in real projects:

1. Similar to on_link_died, perhaps a hook like on_link_start could be provided to know whether other actors have started successfully.

2. Alternatively, a broadcasting feature like BroadcastMailbox (which unfortunately has been closed) could be implemented, allowing other actors to notify the parent actor.

3. I know that PubSub<M> currently exists, but it only supports a single message type. I hope to see something similar to actix_broker that provides convenient multi-message type publishing/subscribing through actix_broker::BrokerSubscribe / actix_broker::BrokerIssue, along with enhancements for global (system) messages or group (arbiter) messages.

Looking forward to more distributed features as well.

[tqwewe]

Thanks for your feedback, very valuable!

1. on_link_start is a very nice idea I haven't thought of. Did you have a particular use case for this in your experience with kameo?

2. I'd still like to explore the possibility of using a broadcast mailbox, however I couldn't find a nice API design I was happy with. But its something I'm open to for suggestions and ideas

3. Improving the usage of PubSub would be great, and having it be a single message type is a little limiting. Thanks for pointing out actix broker, I haven't seen that one before

All great suggestions, and I'll try exploring these when I get more time, thank you :)

[marcaddeo]

Something tangentially related I've been thinking about; would it be possible for actors to know about their parent, child, sibling actor refs when actors are supervised/linked? Is that even a good idea?

When I first started using Kameo, that's how I expected the parent/child supervision to behave (I'm not sure whether or not this is how Erlang/OTP function) but ended up realizing I need to pass the refs manually between the actors that need to communicate with each other.

[tqwewe]

Would an on_linked or on_link_start hook added to the Actor trait solve this @marcaddeo?

[hanekoo]

Something tangentially related I've been thinking about; would it be possible for actors to know about their parent, child, sibling actor refs when actors are supervised/linked? Is that even a good idea?

When I first started using Kameo, that's how I expected the parent/child supervision to behave (I'm not sure whether or not this is how Erlang/OTP function) but ended up realizing I need to pass the refs manually between the actors that need to communicate with each other.

Yes, I've encountered this too.

• Sometimes it's uncertain whether an actor reference is needed within a struct.
• It can also be intrusive to the struct.

[hanekoo]

1. on_link_start is a very nice idea I haven't thought of. Did you have a particular use case for this in your experience with kameo?on_link_start

This mainly depends on the application’s design requirements, especially in applications where actors have strong dependencies on each other.

For example, separating an actor that initializes a TcpStream (init_actor) from the one that processes the TcpStream (process_actor), but with dependencies between them. process_actor depends on whether init_actor starts successfully (though this example may be a bit of a stretch).

It’s a bit like depends_on in Docker Compose, right?

[marcaddeo]

Would an on_linked or on_link_start hook added to the Actor trait solve this @marcaddeo?

Yeah, if that hook contained the actor ref and some sort of "LinkKind::Child" marker to know what kind of link it is. I think that would probably work great.

[tqwewe]

@marcaddeo I've started exploring the addition of an on_linked hook to handle scenarios where an actor is linked with another. The challenge, however, is that the ActorRef for the other actor can't be strongly typed within the trait definition, as it depends on the specific actor being linked. Unfortunately, we also can't use ActorRef<Box<dyn Actor>> due to type constraints.

As a result, the best we can provide in the on_linked hook is the other actor's ActorID. That said, this limitation makes me question how practical or useful the hook would be in its current form with just the actor id of the linked actor.