[erlang-questions] Multiple applications

[Karolis Petrauskas]

Thank you for the comments. It sounds reasonable to go with active
applications. One aspect I forgot to mention is that the main
application should start its own processing only when all the required
plugins are ready. The plugin applications act as backend processors.
Maybe that could be solved in more abstract way: the main application
could be configured with names of processes (or incoming messages) to
wait for before processing is started. Although I am not sure if such
an approach is "erlangish", I was deep in java for last ten years.

Karolis

On Sat, Nov 10, 2012 at 6:15 PM, Garrett Smith <g@REDACTED> wrote:
> On Sat, Nov 10, 2012 at 1:11 AM, Karolis Petrauskas
> <k.petrauskas@REDACTED> wrote:
>> Hello,
>>
>>     I am building an Erlang based system that is composed of several
>> applications. In principle, the system consists of a main application
>> and a number of "plug in applications". The latter have modules
>> implementing behaviours defined by the main application. In this
>> particular case, should I have all the "plug in applications" as
>> library applications, and access them from the main application based
>> on some explicit configuration? Or should all the applications have
>> its own application modules starting own supervisors and then
>> registering self to the main application? The main thing confusing me
>> is the recommendation to have single supervision tree for the entire
>> system.
>
> There are good reasons for taking either approach, but if you're in
> doubt, I'd suggest the second option: each plugin is an "active"
> application (i.e. specifies a mod in the .app file) that registers
> itself as needed with the main application.
>
> The advantage to this approach is that you're further separating the
> components of your system:
>
> - The main application doesn't have to know about the plugins at
> startup, which simplifies its configuration and removes the "wiring"
> logic that it would otherwise need
>
> - Plugins can be added and removed by adding and removing OTP
> applications in the release (i.e. you use boot files to specify which
> plugins are run for a given Erlang process)
>
> The OTP application abstraction in Erlang is very powerful in this
> respect, as long as you design your applications to be as independent
> as possible from one another. You can add new functionality to a
> system by the simple act of starting a new application!
>
> Your only real design consideration then is how the plugin apps
> register with the main application. This is a good spot for a
> gen_event, or pub/sub broker model, where you use an intermediary
> process to broker messages/requests between the main application and
> the plugins.
>
> Garrett