[erlang-questions] Please help me relate a past project to Erlang, I'm trying to understand...

[bill robertson]

Thats good.  Now, to make it *stateful* (and this is the heart of the
question).  Suppose you have the requirement to allow a web user to
view the call as it is in progress and show them who is connected
(telephone number), and how long they have been connected, and also
who is disconnected and how long they were connected.

To do this, you need to track three items for each participant.  The
telephone number.  The start time, and a stop time.

So network request comes in, we have to enumerate those pieces of
information for it and send them back to the client.

How would you implement this in a typical Erlang system?

a)  The process map for the participant (bad answer from what I can glean)
b)  An ets/dets table (there are private ets tables right?  how is
that different from the process map?)
c)  A database of some sort (mnesia, relational, whatever)
d)  Some sort OTP FSM construct?
e)  Other (please elaborate)

If I'm being dense, and you need to use simple words, I won't mind.


On Tue, Mar 17, 2009 at 4:21 PM, Thomas Lindgren
<thomasl_erlang@REDACTED> wrote:
>
>
>
>
>
> ----- Original Message ----
>> From: bill robertson <billrobertson42+erlang@REDACTED>
>> To: Thomas Lindgren <thomasl_erlang@REDACTED>
>> Sent: Tuesday, March 17, 2009 5:24:32 AM
>> Subject: Re: [erlang-questions] Please help me relate a past project to  Erlang, I'm trying to understand...
>>
>> Thanks to all.
>>
>> In this hypothetical case though, the Erlang component must be
>> stateful between requests.  The C server which manages the telecom
>> lines is dumb (which was its power!), and the webapp held no
>> meaningful state (e.g. call duration).
>>
>> While a conference call was in progress, if there were no events, then
>> there was no processing occurring in the conference call manager (the
>> hypothetical Erlang piece).  So when a request comes into the system,
>> it must know its state, act accordingly, send messages etc. and then
>> the request (and control flow and any stack for the request) leaves
>> the system.  In this case then, where would you keep the state?
>>
>> Are you saying that the FSM somehow exists as part of the process if
>> you use the FSM management built into OTP?  (If so then where?  I'm
>> sure it doesn't matter, but...)
>
> All the memory allocated by an erlang process is managed by the runtime system. (Well, as a first approximation...)
>
> How to structure your application? I'd do it like this:
>
> 1. One process per incoming call. This lives for the duration of the call.
> 2. One process per conference call. This lives until the conference call ends.
> 3. One process that starts new conference calls by spawning conference call processes. This process lives forever, the erlang equivalent of a daemon.
>
> Your incoming calls ask the "starter" if there is an ongoing call to join, which makes it either send back the pid of the existing call, or start a new one.
>
> Best,
> Thomas
>
>
>
>