[erlang-questions] Multiple applications

[Garrett Smith]

What makes the plugins "pluggable"? If there's no uncertainly about
what might be registered, it might make more sense to define the
workers as children of a supervisor in your main app.

If you're breaking these into separate apps to manage complexity, then
I suspect you're looking at your option 1 -- library style apps that
are required by the main app.

If it's not know ahead of time what the plugins are, what is the
trigger for processing? Is it a certain number of plugins? A total
worker capacity?

On Sat, Nov 10, 2012 at 4:02 PM, Karolis Petrauskas
<k.petrauskas@REDACTED> wrote:
> 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