[erlang-questions] Re: A discussion in application design and event propagation

Jay Nelson <>
Mon Apr 19 19:57:48 CEST 2010


On Apr 19, 2010, at 10:21 AM, Fred Hebert wrote:

> Without wanting to get too much into a design war (well, this is a  
> design discussion, after all), I usually find it useful to avoid  
> making too many assumptions about the system I'm designing and  
> where it's going to be used, whether it is from a browser, a direct  
> socket connection, or even through XMPP or emails being sent back  
> and forth.

Sorry, posting shorthand.  I meant to differentiate between  
connecting from within erlang (distributed OTP erlang) or from  
outside erlang (browser, email, etc).  The former requires pre- 
configuration with node names, the latter doesn't.  Applications may  
have different choices, but I agree with your goal of loosely  
coupling and "separation of concerns."

> The observation of the game is interesting, but I'm wondering  
> whether it has any importance when considering if you'd want to use  
> process groups or a system like gen_event. In any case, the end  
> result is equivalent, isn't it?

It means 2 pg instances instead of one.  If so, how are they  
related?  One gets game messages (and private deal, etc messages),  
and the other gets some or all messages.  Different rules for the 2  
groups.  gen_event is a good way to forward select messages to both,  
thus my suggestion of using gen_event as a dispatcher and pg for the  
group recipients.  But you may find using a pub/sub solution like  
RabbitMQ a better routing concentrator / filter.  They key feature in  
distributing the messages is latency depending on how real-time the  
game is.

>
> Now about the chat system, I'm thinking this should be part of a  
> different application still exposed to the user. Conflating chat  
> and whatever game/project/system you're building means bundling it  
> with every part of it. If you suddenly want to add Poker to your  
> online casino, you've got to re-write a new chat system for that  
> one. A standalone chat system seems more appropriate from my point  
> of view, but I'm getting a bit off-topic here.

Makes sense.  Now there are three classes of messages (private, game,  
and chat) and two groups (players, watchers) and two communication  
routes (game <-> player and person <-> person).  It seems clear that  
a single pattern (process group or gen_event) doesn't solve your  
problem: you need independently addressable recipients and a  
routing / comms mechanism.

pg treats all recipients equally and relies on them to filter the  
message stream.  pg2 allows you to put the filtering logic in the  
center and group members only receive relevant messages.  But the  
logic in the middle is becoming more complicated, and you see the  
need to let it flexible expand, so I believe there is a relationship  
that you need to capture which decouples addressability / routing  
from selection / filtering of messages.  (Given that you are going  
down the messaging path.)

jay



More information about the erlang-questions mailing list