Make ConditionalRequests extendable

[agido-hundt]

Motivation: It can be useful to have more customized application specific ConditionalRequests. For it the current case class ConditionalRequest must be an implementation of a trait which is handled in the eventuate internal API instead of the case class itself.

@krasserm What do you think? It was not sure about the name of the trait. Do you have a convention here? I thought about deleting the case class completely and name the trait ConditionalRequest as the case class is just used in the tests and documentation. Though this would be a breaking change.

[krasserm]

Motivation: It can be useful to have more customized application specific ConditionalRequests

Can you please describe your use case?

[agido-hundt]

It's just a matter of being more flexible in the implementation of ConditionalRequests.

In our case we have a multiplexing actor which handles just messages implementing a specific trait and forwards these messages to the right recipient.

We now would also like to send ConditionalRequests through this multiplexer. Currently this makes it necessary to have a separate case handling the ConditionalRequest, which gets the internally wrapped message and delegates it to the decision logic.

Having a ConditionalRequest trait would allow us to implemenent our own conditional request wrapper which additionally can implement "our" trait and the message is being forwarded to the correct recipient without additional handlers.

[krasserm]

So you want to have this change in Eventuate to have a more convenient implementation of your multiplexer (assuming it handles messages that implement a special trait), right? Although I can understand that this would make things easier to implement, your approach nevertheless doesn't scale. For example, if you'd like to multiplex Akka's PoisonPill or any other pre-defined message type, you'd have the same problem again. This is also the case for any third-party command library that you're using.

What do you think about extending the special trait (used by the multiplexer), let's name it Multiplexed here, with an additional method that extracts the message to be sent to the targets? This method would return the message itself if it directly implements Multiplexed, otherwise, if a container implements Multiplexed, it would return the contained message. You would then use the container for ConditionalRequest as well.

[agido-hundt]

Ok, good point. Thanks for your advice. Closing this.