[erlang-questions] Re: non-trivial supervisor idioms?

Mazen Harake <>
Tue Sep 28 08:05:17 CEST 2010


  On 28/09/2010 08:09, Steve Davis wrote:
> I defined mnesia/
> crypto and other dependencies as included apps and started their own
> sups under the main app sup (as recommended
> http://www.erlang.org/doc/design_principles/included_applications.html).
I'm not sure this is a good idea imho, I think included applications are 
meant to be used for your own specific applications only and not the 
generic ones like mnesia, crypto etc. I could be wrong but doing it the 
way you described just feels wrong.

The way I understand included applications is that lets say you build 
application A1.0 and you want to generalize some part of that and move 
that part into its own application B1.0. Application B in this case 
doesn't make sense on its own (I.e. you remove application A) but it 
does make sense in the way that if you want to build a new A, and make 
it A2.0 then B1.0 could still apply (perhaps it implements some core 
protocol or what ever). In THIS case it would make sense to have 
application B as an included application and not as a primary 
application. However, I usually start all applications as primary 
applications and specify dependencies instead. I make the 
assumption/argument that if Application B can't start up then there is 
no point for A to start thus the normal boot up sequence is most of the 
time (I'd say 98%) good enough.

The way I usually handle the scenario OP mentioned: always make sure 
data, configuration, mnesia tables exist and are sane in the start 
function of my application (myapp:start/2). You can spread out the 
various test functions in their respective modules to encapsulate the 
functionality (E.g. myapp_data:check_fix(), myapp_conf:validate(), 
myapp_db:ensure_tables() etc...) but essentially it is all tested from 
the application's start function. I _never_ start other applications in 
my application... I believe this is unnecessary and that it makes the 
release centered around  one application and I rarely write a system 
where I have a release with only one application.

I have personally very little experience with start phases but I have 
never come across any situation that couldn't be solved in a 
(conceptually) equally good way.

My 2 cents :)

/Mazen


More information about the erlang-questions mailing list