[erlang-questions] OTP application design

Kirill Zaborski qrilka@REDACTED
Tue Jun 12 20:51:24 CEST 2007

Vlad, thanks for your explanations but you missed the point :)
I was writing about other task. I understood quite clearly (I think) what
you have proposed.
But I have also a task (for testing purposes) to write a worker emulator
(apart from actual workers) or maybe a couple of emulators with a different
logic. And those emulators should act like normal workers (which will be
gen_server+API) so they must implement handle_call({work,Data}) and I can
not use some behavior to declare API common to both "normal" worker and
worker emulator.
Maybe just Java coding at day time plays role here and I want to use
interfaces every time. :)


On 6/12/07, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi,
> On 6/12/07, Kirill Zaborski <qrilka@REDACTED> wrote:
> > Thanks, quite reasonable.
> > But implementing  an emulator for worker seems a bit ugly - I won't be
> able
> > use "normal" behavior so I will need gen_server with
> > handle_call({work,Data}) (taken from your example).
> Mmm, that's not an emulator or wrapper for the worker. The
> gen_server:call has two arguments: a reference to the process running
> the code, and the message to be sent.
> For your dispatcher, the reference is ?MODULE, presumably because the
> process was registered with that name (dispatcher). Since the name is
> known at compile time, the external API need not include it (i.e
> dispatcher:action needs only one argument)
> For the workers, the reference  will have to be the Pid of the
> process. The API will have to reflect that, worker:action has two
> arguments, the identity of the process and the message.
> Behind the scenes, the gen_server:call will take the {work, Data}
> message, wrap it up in an internal strucure and send that. The
> gen_server behaviour unpacks it and dispatches it to the appropriate
> handler (handle_call, handle_cast, handle_info).
> I hope this is clearer.
> Regards,
> Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070612/dbc23c11/attachment.htm>

More information about the erlang-questions mailing list