[erlang-questions] OTP application design

[Kirill Zaborski]

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. :)

Regards,
Kirill.

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>