[erlang-questions] grpoc for session management

[Ulf Wiger]

Pablo Platt wrote:
> Hi
> 
> I'm building a simple comet chat server. Each user can have several
> resource each represented by a process. Each incoming message should
> be sent to all online resources of a user.
> 
> There are two scenarios in which I need to find a process: 1. message
> is directed to:user_id 2. incoming message contain a session_id
> 
> Is it better to have a unique name per user_id+resource and then use
> gproc:select to find the pids of the resources or to use a property
> user_id and then find all the pids that have this property.

Part of the idea with gproc was that you should be
able to do either. Which one is best for your problem is
probably up to you. :)


> Is it better to use gen_fsm(to handle auth for example) for each
> process or a simple process?

Some people like gen_fsm. It provides structure, and is
suitable e.g. when implementing a FSM from a specification,
since they tend to be described that event-state matrix form.

What I dislike about gen_fsm is that it does away with
selective receive, which can often be used to simplify the
state machine. Then again, there are many FSMs where this
doesn't matter (you still have the benefit of selective
receive when calling support functions from within the
gen_fsm callback, for example).


> Will gproc support global scope in the near future?

In the experimental branch (never mind the name, this is
the recommended branch), the code has been restructured
so that you get to provide the gen_leader options yourself.
You can then also choose which version of gen_leader you
want to run. There are a few versions out there, particularly
on github.

The only real problem with the latest gproc version is that
the global support hasn't been tested. :)
Almost by definition, this means it doesn't work, but I
expect there to be only minor issues, quickly fixed.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

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

WE'VE CHANGED NAMES!

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

www.erlang-solutions.com