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

[Mazen Harake]

I try to think of even_handlers as something you dynamically hook in to 
and which is a design choice by the hook-ie (so to speak :), I didn't 
want to end that word with -er), not part of a static design. E.g. if 
you have a black jack table then the processes that are created (read: 
the players that have joined the table) will always receive events to 
the table and they will never ignore the events of the table (read: 
unregister/re-register) then there is no point in the dynamic nature of 
event_managers/handlers (and thus the overhead, complexity etc).

Using this reasoning I would vote for "The second way".

But as you said they are essentially the same thing and either way I 
reckon that the data transform and manipulation would be done at the 
Table level either way (before it is sent to the clients).

My 2 cents :)

/Mazen

On 18/04/2010 22:50, Fred Hebert wrote:
> I'm starting this thread to spark a discussion about Erlang software design.
> I've been writing a few applications here and there and I've noticed a few
> common patterns occurring over time, but with not clear solution to them.
> That seems to be due to the general "there is more than one way to do it"
> attitude that exists when organizing processes, and not  because of a lack
> of activism.
>
> Anyway, the design question comes from designs having to do with multi-user
> activities, might it be chat rooms, games of cards over the web, voting
> system, a pub-sub mechanism, etc. The general idea is that you have a group
> of users and a sequence of events that has to be forwarded to every user in
> real time. To make this clearer, I'll take the example of a blackjack table
> where every player has a GUI showing the state of the game.
>
> You'd have (I imagine) one process representing the dealer and the table
> (D). Then you have 3 players, P1, P2 and P3, each represented as a process.
> A hand distribution goes like this:
>
>
>     1. Player 1 registers to the table
>     2. Player 2 registers. Player 1 is notified of this.
>     3. Player 3 registers, P1 and P2 are notified.
>     4. The game starts, All players are notified of this.
>     5. Each player (and the dealer) is handed a card
>     6. Players bet. All players are notified of this;
>     7. ...
>     8. etc.
>
> Then you could also have some messages private (imagine having a private
> hand as in a poker game or whatever).
>
> There are two obvious ways I can think of to model this. The first one is as
> a gen_event process and handlers, where all players register an event
> handler. When an event occurs, either the dealer or the players notify the
> event manager which then forwards the event to subscribers through their
> respective event handlers. The second way I can think of are process groups,
> where a message sent to the leader is automatically forwarded to all
> processes who are members of the group.
>
> It seems to me these are equivalent solutions, as they allow for the same
> propagation of events in correct order. However, the former runs the
> filtering and forwarding functions in the event manager's process and the
> latter does it in each of the group's processes. This makes it look like the
> process groups would make it easier to scale (you can forward the message at
> once and then the evaluation takes place wherever it needs to be), although
> it would have a higher amount of messages being sent around because no
> filtering could take place beforehand.
>
> So here's to launch the discussion. What would you think would be the best
> choice in this case? and otherwise, what other options do you see? What are
> the pros and the cons of each? Both options seem valid, but I don't remember
> seeing them being discussed too much.
>
>    

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com