Hi Brian,
thanks a lot for your help.
- Reto
On Wednesday, August 9, 2017 at 8:47:14 PM UTC+2, Brian Smith wrote:
>
> Hi Reto
>
> You're right, replyTo won't make sense with ask unless the client is an
> actor.
>
> Differentiating on the type of message should work.
>
> Cheers
> Brian
>
> On
Hi Reto
You're right, replyTo won't make sense with ask unless the client is an
actor.
Differentiating on the type of message should work.
Cheers
Brian
On 9 August 2017 at 18:16, Reto Hablützel wrote:
> Hi Brian,
>
> thanks a lot for your response.
>
> What would the setup look like to work n
Hi Brian,
thanks a lot for your response.
What would the setup look like to work nicely with ask? I believe I would
need the flag, which is what I wanted to avoid:
Approach 1: *target ? Event(responseWanted = true)* --> this would work,
the processing actor could determine the sender and just
Hi Reto
Not an expert but I'm not sure about the motivation here.
What's wrong with the client deciding to use ask or tell based on whether
it wants a response or not (and communicating that preference to the actor
using the replyTo pattern you've identified)?
What do you gain by making the choi
Hi,
I have a use-case where the sender of an event shall be able to specify
whether the event shall be processed in the background or an answer is
expected. I wanted to express these semantics by specifying a 'replyTo:
Option[ActorRef]' in the message rather than adding a flag to the message.
