Application structure

[Ulf Wiger]

My apologies - this reply got stuck in my drafts box for far
too long. I see noone else has replied to your question, so
I will send what I had written. Sorry if incomplete.

/Uffe

On Sun, 13 Apr 2003, Walter C. Reel III wrote:

>I'm trying to learn Erlang and create a 'Proof of Concept'
>system at the same time. I came across the Application
>structure in the 'Design Principles' documentation.  Would
>it be better to start from this structure and work upwards?
>It would seem there is a lot of built in functionality that
>relates to the application structure.

You should probably not try to comply to all of it at once.
Some basic initial steps could be taken to ease the
transition into more complex stuff later:

1) File structure

Organize your code into App/src, App/ebin, etc.
Try to keep the organization symmetric, e.g.
MyLib/App1
     /App2

You do not really have to dive into .app files and boot
scripts. If you want ready access to all your code, you can
add instructions in a .erlang file in your home directory
(assuming you're using UNIX):

code:add_paths([".../MyLib/App1/ebin", ...]).


2) Behaviours

If you use e.g. gen_server, it will be easier to adapt
your code to a supervision structure, and applications,
later.


3) Nodes and applications

>If so, does a node correspond to an application?  The
>mnesia schema would go under 'App/priv' or
>'App/priv/schema', right?


A node is one instance of the Erlang VM. You can run several
interconnected VM instances on the same machine, or on
different machiens across a network. OTP Applications are a
way of grouping modules and processes into a logical entity
that can be started, stopped or upgraded together.

Each OTP library (stdlib, kernel, inets, etc.) is an
application. Some (e.g. stdlib) do not actually start any
processes when starting the application (they can still be
started and stopped, but mainly for consistency and
convenience.)

A common setup is to keep the same code on all nodes -- i.e.
identical application trees. One very good reason for doing
this is to avoid having different versions of the same
module in the system. You may also start each node with the
same boot script, and rely on the OTP application controller
to decide which applications should run where.

Given this, naming the mnesia directory e.g. priv/mnesia or
priv/schema will work as long as you have only one node. The
default name for the mnesia directory is Mnesia.<nodename>.
You can have a similar setup under your priv/ directory, but
I would propose instead a habit of creating a
<systemname>.<nodename>/ directory, and under it, e.g. a
mnesia/ directory, logs/, etc. This will allow you to test
your system running several nodes on the same machine -- a
very nice aspect of Erlang.

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