support different service interaction models

[rjrodger]

the load balancer maintains a list of target services to send messages to the are different types of message pattern:

actor => select one target from the list of targets (and select using round-robin, random, etc) publish => send to all subset => only send to 2; only send to 10%, etc

provide a configuration mechanism to support these patterns

in particular actor and publish, as they are really fundamental

Q: is this orthogonal to strategies (such as round-robin)? feels like it is...

[mcollina]

I am not sure that calling this "message pattern" is a good naming idea.

Seneca is all about pattern matching, but the order is important and things will get messy and confused.

Also, I'm not getting how this is different from #4.

[rjrodger]

"service interactions"?

differs form #4 as orthogonal

e.g.

if the "service interaction" is actor and the strategy is round-robin, then each target gets 1/n messages ordered by arrival

if the "service interaction" is publish and the strategy is random, then each target gets n/n messages (all!) and the strategy is not relevant

[rjrodger]

Let's go with model

Implementation: add model property to plugin options: seneca().use('balance-client', {model: function(){ ... } })

model can be a built-in: actor, publish, etc (string value is used as abbreviation)

The model function needs, I guess, the list of targets, the callback, ... perhaps some other context?

[cjihrig]

I think I agree with the idea that this and #4 should be treated as the same thing. I think #3 could go under the same umbrella. These all just seem like different ways of stating the routing policy, and trying to split them into separate options seems like unnecessary added complexity.

[rjrodger]

agreed - we have enough "power" in the current model-based parameterization functions to handle these cases, so let's not gild the lily