[erlang-questions] pattern to augment a release with a plugin system

Benoit Chesneau bchesneau@REDACTED
Thu Nov 26 11:37:20 CET 2015

Hi all,

I am actually working on a system to augment a release possibly dynamically
with some extensions.

For now in hooks [1] I am starting applications from the filesystem or just
using the applications shipped with the release. I am not a fan of simply
starting/stopping applications from the filesystem since for now it is not
handling upgrades (only by starting/stopping the application) like a
release can do.

I can see these different ways to handle plugins right now:

1) plugins are only added at compile time (something rabbitmq does).
Similar to 1

pro: plugins are the simple apps
- the system is not dynamic and a user can't simply augment the application
he is using. Only plugins built and shipped with the release are available

2) adding plugins to a release and possibly starting them when enabled via
the config. The upgrade would be done via a release upgrade.

- doesn't change too much the current way to handle releases upgrade.
- the plugins can be added dynamically

- if i want to add a new plugin I will need to create a new release,
increment its version etc.
- Also a new release would have to be build for each users depending on
their choice.
- I have to find a way to build a local release based on remote plugins
depending on the platform

3) load plugins via an external system. If this is an apps, it will be
installed using the release_handler, so it could possibly manage  the
.appup scripts

pro: plugins are really dynamically handled

- not sure on how with the release_handler the installed application will
be handled at startup.
- not sure if dynamically augmented release using the release_handler is

4) Something similar to 3 , but instead of using the release_handler, i
have my own plugin_handler handling upgrades by looking on specific modules
functions if needed.

Are there other ways to do it? What would be the right pattern to do it? To
be honest I am balancing between 2 and 3. 4 would be fine but would mean
rewriting something similar to the release_handler.

Generally speaking how people feels about augmenting dynamically a release
with new applications/modules ?

Any feedback is welcome.

- benoît

[1] https://github.com/barrel-db/hooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151126/55b1c8e8/attachment.htm>

More information about the erlang-questions mailing list