[erlang-questions] prep_stop in an included application

[Ulf Wiger]

Alex Vazquez wrote:
> 
> Anyway, just for curiosity, there would be any reason preventing some
>  kind of stop_phases scheme or it's just that nobody found it that 
> necessary and/or had the time to do it?

Others may remember it differently, but this is my recollection.

Back in 1996, when the AXD 301 project got started using the
very first version of OTP, we fairly quickly ran into some
problems. For sure, we had a very complex product to write*
but we also had many more people than one would wish for in
a first iteration of the system.

* Piling the initial specifications on top of each other,
they measured about 3 ft.

One consequence was that we ended up with multiple teams
working on the same application. To manage this, we split
the application into sub-applications and wrote a build tool
to merge them into one big .app file. This was the precursor
to included applications.

We also found that it was very difficult to manage the start
sequence of applications with several processes and complex
dependencies during initialization. After a period of writing
messy code with processes casting to themselves and then
rushing to get all the work done before someone thought to
start using the APIs, we developed a form of start phases
through use of environment variables (as I described previously)
and a central start function.

These two things eventually made it into OTP, in a slightly
modified form. At the same time, AFAIR, the application
behaviour was invented. By this time, OTP was used in several
other projects, and it was reasoned that since the
implementation meant that /any/ application could be made
included just by adding it to the 'included_applications'
attribute of another application**, it might not always
be a good idea to call the original start functions etc.
If the application had been designed under the assumption
that it was a "top-level application", it might end up
doing things that were not appropriate under the given
circumstances.

** This was actually another requirement from the AXD
project, since we wanted to be able to include applications
such as snmp, inets, etc. The reason for this was that we
needed them to move together with other O&M components
during failover and takeover. Many years later, we invented
ways to handle the synchronized switchover without bundling
everything into one app.

Much later, we observed that it could also be quite problematic
to stop these complex applications, and that some form of phased
shutdown would sometimes be useful. That's when the prep_stop
phase was invented. It was reasonable to give it similar
semantics to the start, start phases, and stop callbacks.

Does that satisfy your curiosity?

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com