[erlang-questions] Implement standard API (was process hierarchy and passing references)

Vance Shipley vances@REDACTED
Fri Aug 15 19:10:08 CEST 2014


Yes. ;)
On Aug 15, 2014 7:46 PM, "Frans Schneider" <schneider@REDACTED> wrote:

> Yes, I guess defining my own behaviour is what I am looking for.
> Found Cascading Behaviours (http://erlangcentral.org/wiki/index.php?title=
> Cascading_Behaviours) which seems to do the trick.
> It is a little dated and still uses behaviour_info(). Is it possible to
> reuse the callback definitions from gen_server?
>
> Frans
>
>
> On 08/15/2014 04:02 PM, Ladislav Lenart wrote:
>
>> Hello.
>>
>>
>> On 15.8.2014 11:49, Frans Schneider wrote:
>>
>>> Hi list,
>>>
>>> Now that I got the supervision working, I am looking for a way to
>>> implement a standard API for every "main" server. The API implements a
>>> way for the main gen_server to call the RPC middleman and should also
>>> define standard callbacks for the main server the middleman can use. The
>>> API would also use some internal state. In a previous life, I would have
>>> used inheritance to accomplish this, but how can I do this in Erlang?
>>> I had a look at the supervisor implementation, but was wondering if
>>> there is a easier way to accomplish this.
>>>
>> I am not sure I follow you completely. However, if you want to parametrize
>> process behavior in Erlang (i.e. something similar to OO inheritance that
>> you
>> mentioned), you can define your own behaviour (a module) and define
>> different
>> callback modules that all implement it. The pattern is the same as with a
>> gen_server behaviour.
>>
>> If this is not what you need, please provide us with a concrete
>> example(s) that
>> you currently struggle with.
>>
>>
>> HTH,
>> Ladislav Lenart
>>
>>
>>  Thanks
>>>
>>> Frans
>>>
>>>
>>> On 08/14/2014 05:16 PM, Ladislav Lenart wrote:
>>>
>>>> Hello again.
>>>>
>>>>
>>>> On 14.8.2014 17:00, Ladislav Lenart wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> What about the following solution:
>>>>> * Put all three processes under one supervisor.
>>>>> * Set its restart strategy to one_for_all.
>>>>>
>>>> Or rest_for_one. This one may better suite your needs. For more info,
>>>> refer to
>>>> the official documentation at: http://www.erlang.org/doc/man/
>>>> supervisor.html
>>>>
>>>>  * Pass supervisor's PID to its children.
>>>>> * Each worker process can lookup PID of its relevant sibling via
>>>>> supervisor:which_children/1.
>>>>>
>>>> HTH,
>>>>
>>>> Ladislav Lenart
>>>>
>>>>
>>>>  On 14.8.2014 16:48, Schneider wrote:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> Since I am very new to Erlang, I am not sure how to layout process
>>>>>> hierarchies in the following case:
>>>>>>
>>>>>> Besides the domain specific functionality, every program has a RPC
>>>>>> middleman and an XML-RPC interface, each implemented as gen_servers.
>>>>>> In
>>>>>> the current setup, the main gen_server process starts the RPC
>>>>>> middleman,
>>>>>> passing it its Pid, and the RPC gen_server starts the XML-RPC server
>>>>>> which is passed the RPC middleman's Pid.
>>>>>> Using the passed in Pid's, the XML-RPC server can do a
>>>>>> gen_server:call()/cast() back to the RPC server which on its turn can
>>>>>> call the main server. Works ok, but I would like to have the RPC
>>>>>> middleman and XML-RPC controller under the control of a supervisor.
>>>>>> The
>>>>>> main supervisor should start the main gen_server process plus a
>>>>>> supervisor that on its turn should start the RPC midleman and the
>>>>>> XML-RPC handler.
>>>>>> The thing I can't figure out is how the XML-RPC process should find
>>>>>> the
>>>>>> RPC middleman process and how that process should locate the main
>>>>>> server
>>>>>> when using supervision. Since there can be many RPC middlemen and
>>>>>> XMP-RPC servers around, each belonging to different main servers,
>>>>>> naming
>>>>>> and registering seems a little hard.
>>>>>> So how to pass references around?
>>>>>>
>>>>>> Any help will be very much appreciated.
>>>>>>
>>>>>> Frans
>>>>>> _______________________________________________
>>>>>> erlang-questions mailing list
>>>>>> erlang-questions@REDACTED
>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>
>>>>>>  _______________________________________________
>>>>> erlang-questions mailing list
>>>>> erlang-questions@REDACTED
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>
>>>>>  _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140815/3c6cccc1/attachment.htm>


More information about the erlang-questions mailing list