How would you call modules that work by using processes? Services? Dynamic Erlang modules? (Can’t really call them behaviours because there are cases when they are not used).
A module that is a set of functions seems to be more straightforward as it could be called a library. But then again, that module could also utilize one-off processes so the previous description could also fit here…
A concrete example would be the SASL application which comprises
-
Error logging(deprecated) -
Alarm handling refers to a
gen_event
event manager process launched on SASL startup with one default alarm handler -
Report browsing (deprecated?) is also implemented as a
gen_server
-
systools
, an Erlang module consisting of a set of release handling functions
Background for this question
Was reading Adopting Erlang to get into using Rebar3, and the Releases chapter mentions that even though rebar3 new release
command will always include sasl
in the relx
template in rebar.config
, the examples in the chapter removed it “since we are focused here on creating containers which are replaced instead of live upgraded so sasl does not need to be included.”
Trying to convert an old project into a proper OTP application and release, but not using containers (yet) so looked the SASL docs whether I should include it or not. In the end, I had to look into the source to figure out as I found the wording of the docs confusing - but also realized that I have no clue how they could be made less ambiguous…
For example, the SASL User’s Guide’s Introduction starts with
The SASL application provides support for:
- Error logging
- Alarm handling
- Release handling
- Report browsing
(completely omitting systools
) and the sasl
man page in the Reference Manual uses the word “services”
Description
The SASL application provides the following services:
- alarm_handler
- release_handler
- systools
but “service” doesn’t feel right here.
The application-related terminology in Adopting Erlang is great but then parts of an application is a different kettle of fish.
we’re going to use the following terminology for OTP Applications for this entire book:
- Library Applications: stateless collections of modules
- Runnable Applications: OTP applications that start stateful supervision tree structures with processes running in them
- OTP Applications: either Library or Runnable Applications, interchangeably