Feature Suggestions

[jano7]

• Add try_send function to the context: it will return a failure immediately if the channel is full.
• Optionally add try_send_with_timeout: returns error if the channel does not get freed within a timeout. Basically tokio::time::timeout(duration, ctx.send(...)).await.
• Add update function to the context: backed by the watch channel type.
• As a complement to update allow actors define async fn handle_update(&mut self, envelope: &Envelope<Self::Event>) -> Result<()>.
• Allow actors to define async fn handle_event_miss(&mut self, envelope: &Envelope<Self::Event>) -> Result<()> alongside handle_event: an actor defining this method removes the back-pressure and is prepared to miss an event if slow. (Backed by broadcast channel.)

These are a bit more vague:

• Add a built-in support for a backoff strategy when handling of a message fails: the strategy will dictate when the problematic event gets retried.
• Add ability to create/destroy actors at any point during the app execution.
• Create a dedicated channel for actor lifecycle events: start/stop/failure.

[ddrcode]

Thanks for sharing your ideas, @jano7 - I like them. The watch channel will have massive value in many use cases. If I understood it correctly - your proposal is to always have a pair of channels for every actor - the "standard" bounded channel for event stream and watch channel for system, state changes, is that correct? I was thinking about the watch channel use case but more in context as a replacement for bounded channel - so you either watch or stream. In your proposal we have two parallel data flows working in separate domains. Always. Do you have a specific use case in mind, so I could better visualise the idea?

The try_send is slightly more tricky. On the surface it feels like just an extra method to the Context, but in reality it has important consequences. ctx.send().await says: wait if the broker's channel is full. Maiko chooses bounded channels with backpressure. When the broker can't accept more events, producers wait. This couples senders to system capacity - by design. Means stable system, explicit behavior. By loosing the coupling we are risking data loss, outside of broker/supervisor control - it's actor that decides to "fire and forget". On top of that - in the discussion on backpressure (#44) I proposed that one of potential OverflowStrategy could be Block. Case when we neither fail nor drop events on overflow, but we block the system until consumer handles some events. It's not decided yet it will be implemented that way, but if it will - then ctx.try_send() will break the OverflowStrategy::Block. If we want the Supervisor and Broker to have control - then try_send gives too much freedom. If we prefer user (actor) to decide what's good, then try_send is the way to go. Perhaps it should be marked as unsafe then :-)