<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/26/2015 02:37 AM, Benoit Chesneau
wrote:<br>
</div>
<blockquote
cite="mid:CAJNb-9qTRDn8+-rQzMxP8K+a+i3FM=qEoTP8Sbjze7PRBkAxAw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>I am actually working on a system to augment a release
possibly dynamically with some extensions. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I can see these different ways to handle plugins right now:</div>
<div><br>
</div>
<div>
<div>1) plugins are only added at compile time (something
rabbitmq does). Similar to 1</div>
<div><br>
</div>
<div>pro: plugins are the simple apps</div>
<div>cons: </div>
<div>- 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</div>
</div>
<div><br>
</div>
<div>2) adding plugins to a release and possibly starting them
when enabled via the config. The upgrade would be done via a
release upgrade.</div>
<div><br>
</div>
<div>Pro: </div>
<div>- doesn't change too much the current way to handle
releases upgrade.</div>
<div>- the plugins can be added dynamically</div>
<div><br>
</div>
<div>Cons: </div>
<div>- if i want to add a new plugin I will need to create a new
release, increment its version etc. </div>
<div>- Also a new release would have to be build for each users
depending on their choice.</div>
<div>- I have to find a way to build a local release based on
remote plugins depending on the platform</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>pro: plugins are really dynamically handled</div>
<div><br>
</div>
<div>cons: </div>
<div>- not sure on how with the release_handler the installed
application will be handled at startup. </div>
<div>- not sure if dynamically augmented release using the
release_handler is suppored</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Generally speaking how people feels about augmenting
dynamically a release with new applications/modules ?</div>
<div><br>
</div>
<div>Any feedback is welcome.</div>
<div><br>
</div>
<div>- benoît</div>
<div><br>
</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://github.com/barrel-db/hooks">https://github.com/barrel-db/hooks</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<tt>Having Erlang applications started and stopped dynamically can
be contrary to having the system fail-fast. So, that is a danger,
since you are not always starting from a known starting state, the
dynamic actions are dealing with state that is unknown due to the
point in time during the runtime when the actions execute. There
is only one boot file which the Erlang VM accepts on its command
line, and that contains the list of actions which are suppose to
provide a successful startup of the release, and if not, it should
crash due to validation during initialization.<br>
<br>
However, it is helpful to be able to dynamically start and stop
Erlang applications, if the system has dynamic functionality it
needs to support (hopefully with careful validation in isolation,
so it doesn't cause instability). I have functions for this at
<a class="moz-txt-link-freetext" href="https://github.com/okeuday/reltool_util">https://github.com/okeuday/reltool_util</a> . You might like
reltool_util:application_remove/3 since that handles dependencies
too, if they aren't shared with other applications. I prefer
reltool_util:application_start/3 instead of
application:ensure_started/1 since it handles module loading too.
The reltool_util module also contains functions for handling
release boot and script files.<br>
<br>
Best Regards,<br>
Michael<br>
</tt>
</body>
</html>