[erlang-questions] Application naming question

[Mike Oxford]

You may consider writing a "generic" monitor, and then interface-specific
callback handlers.

eg, dev_mon and then you tell it "if1_event1 call handle_event_if1_event1"

In this case you separate out the "handling logic" from the "monitoring
logic."  You will need to maintain multiple sets of handlers (one per
interface) but then you're not duplicating the routing/monitoring parts.

Also, and I've done this, is to have a "default handler" and all messages
which don't match the specific handler get shunted to the default handler.

eg,

event received -> lookup/match to specific handler -> route to if1_handler
 -> no_match -> route to default_handler -> drop on floor/throw
error/whatever for a no-match condition.

This works well for putting in "global catchall handlers" and also works
for "overriding handlers."  (eg, if1_handler -> subclass_handler ->
class_handler -> default_handler)

-mox

On Mon, Sep 24, 2012 at 8:54 AM, Matthew Evans <mattevans123@REDACTED>wrote:

>  Hi,
>
> I have an application (let's call it dev_mon) that is responsible for
> listening to, processing and emitting events on a hardware interface. This
> application contains 3 supervisors and many registered gen_server
> processes. Currently we have a single interface that requires supervision.
>
> Future hardware revisions will expose multiple interfaces that requires
> dev_mon to monitor. Obviously I can handle this in the code, however I
> believe a better solution would be to have multiple instances of dev_mon
> for each interface.
>
> In this case I would have application dev_mon_if1, dev_mon_if2,
> dev_mon_if3 etc.
>
> The only way I can think of to implement this is to write 3 separate
> application files (in their own directories) along with their associated
> Erlang app files. For example:
>
> dev_mon_if1/ebin/dev_mon_if1.erl
> dev_mon_if1/ebin/dev_mon_if1.app
>
> dev_mon_if2/ebin/dev_mon_if2.erl
> dev_mon_if2/ebin/dev_mon_if2.app
>
> dev_mon_if/ebin/..all the other beam files shared between all instances..
>
> The ".app" file would contain an env property that ensures the registered
> supervisors and gen_servers are unique (e.g. if1, if2 etc).
>
> i.e. not do:
>
> start_link() ->
>
>     gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
>
>
> Instead to:
>
>
> start_link(RegName) ->
>
>     gen_server:start_link({local, RegName}, ?MODULE, [], []).
>
>
> Where RegName is an atom like 'if1_monitorapp'.
>
>
> Question: Is there a better way to do this?
>
>
> Thanks
>
>
> Matt
>
>
>
> _______________________________________________
> 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/20120924/98e7739c/attachment.htm>