Open hanekoo opened 3 days ago
Thanks for your feedback, very valuable!
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?
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
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 :)
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.
Would an on_linked
or on_link_start
hook added to the Actor
trait solve this @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.
Yes, I've encountered this too.
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?
Would an
on_linked
oron_link_start
hook added to theActor
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.
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:
Similar to
on_link_died
, perhaps a hook likeon_link_start
could be provided to know whether other actors have started successfully.Alternatively, a broadcasting feature like BroadcastMailbox (which unfortunately has been closed) could be implemented, allowing other actors to notify the parent actor.
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 throughactix_broker::BrokerSubscribe
/actix_broker::BrokerIssue
, along with enhancements for global (system) messages or group (arbiter) messages.Looking forward to more distributed features as well.