[erlang-questions] Application naming question

[Matthew Evans]

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

[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

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions