Web applications unification

[Ulf Wiger]

On Wed, 28 May 2003, Mikael Karlsson wrote:

>I guess a good starting point for such a framework would be
>that one should implement the generic behaviour API then,
>so that a supervisor can start the application or by using
>application:start.

If you have a runnable application, you need to write a
start/2 function and define it in an .app file. In most
cases, such a start function would call
supervisor:start_link(), and while this is definitely
recommended, it is no requirement.

There are other ways to start an erlang node, e.g. using the
-s flag and then calling application:start() (which assumes
the existence of an .app file), or simply spawning
processes. For a robust framework, we should definitely go
with the OTP way of doing things, since it works well, and
comes with both support and documentation.

>If you provide a library with no processes, like xmerl,
>then there is of course no need for this.

Correct.

>Then you have a choice of using builder and making .app,
>.rel, .script and .boot files or using application:start in
>your own code?

If your applications do not have a start function, using
builder will still give you the benefit of a start script,
always picking the latest version of each application (if
that's what you want, otherwise, a specific version of some
app) and making sure they're in the path, and semi-automatic
configuration of environment variables.

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes