Currently I'm investigating if I can effectively have bidirectional channels and it seems like it possible and reasonable. The benefit is that an Actor can receive a message and then reply without it knowing or caring where the message came from. This can be useful for things like a "keep alive" or "Am I alive" type interaction. Currently I'm testing it out in client and server and it feels OK and I'm going to flesh out how to actually accomplish this.
The upside to that if makes the actor code simpler, but that means for a broadcastd message a "fake" Sender<BoxMsgAny> would need to be created and the Actor wouldn't be able to know. Based on that I'm thinking I'll keep reply_tx an Option but we'll see.
Currently I'm investigating if I can effectively have bidirectional channels and it seems like it possible and reasonable. The benefit is that an Actor can receive a message and then reply without it knowing or caring where the message came from. This can be useful for things like a "keep alive" or "Am I alive" type interaction. Currently I'm testing it out in
clientandserverand it feels OK and I'm going to flesh out how to actually accomplish this.But while doing this there is a question should I always assume there is a bidirectional connection, if I always do that then instead of trait object
fn process_msg_anyreply_txparameter have to be optional: https://github.com/winksaville/exper_inter_process_channel/blob/0eb7a71ae3c48e359e4aefc129ed87aca557d7fc/actor/src/lib.rs#L76 it could be just borrowed.fn process_msg_any(&mut self, reply_tx: &Sender<BoxMsgAny>, msg: BoxMsgAny);The upside to that if makes the actor code simpler, but that means for a
broadcastd message a "fake"Sender<BoxMsgAny>would need to be created and the Actor wouldn't be able to know. Based on that I'm thinking I'll keepreply_txanOptionbut we'll see.