mod key and its role in resourse file

Wiger Ulf ulf.wiger@REDACTED
Mon Dec 30 21:37:33 CET 2002


Hi Suresh,

The passage about the 'mod' key refers to so-called "included applications".

It is possible to create a hierarchy of applications, where several
different applications are combined into one complex application. This can
be very useful if you need to create a large "run-time complex", but still
want to break things up into manageable units. Also, if you have several
programmer teams each working on a certain part, it is convenient to allow
them to package their own code as an application, and then build larger
applications out of several smaller ones.

The way to create a hierarchy of applications is to specify sub-applications
in the 'included_applications' attribute of another application. This will
be recognized by the release handler and the application controller.

When starting the application, the OTP application controller only cares
about the topmost application, and uses the 'mod' key in it to identify the
start function. It is then up to that start function to create any processes
needed by the sub-applications.

To be precise, the sub-applications are allowed to have a 'mod' key as well;
it is just ignored by the application controller.

In AXD 301, for example, the ATM signaling application is a fairly large
complex of smaller applications (each ATM signaling protocol is an
application; generic call control is another; resource handling, admission
control, routing, etc. are also applications. They all make up one large
(hierarchical) application, where the startup and recovery procedures are
tightly integrated using "start phases" (another feature of the application
controller).

In AXD 301, all applications have the same 'mod' key ({sysApp,
{sysAppCB,[]}}), where sysApp:start(Type, ...) (an AXD 301-specific
function) takes care of starting the topmost application as well as all
included applications. It is not terribly difficult to write such a
function, and it can use application:get_key(App, included_applications) and
application:get_key(App, mod) to extract the information needed to start
included applications automatically.

Regards,
Ulf Wiger

----- Original Message -----
From: "Suresh S" <sureshsaragadam@REDACTED>
To: "Wiger Ulf" <ulf.wiger@REDACTED>
Cc: <erlang-questions@REDACTED>
Sent: den 30 december 2002 12:13
Subject: mod key and its role in resourse file


> Hi Ulf
>
> I have some other OTP Based applications like mnesian,
> eva,.. inculded in my applications
>
> Acoording to Design Principles of OTP it says
>
> Included Applications
> ---------------------
> if you want several applications to include an
> application, it has to be designed as a library
> application without a start function (the mod key in
> the .app file).
>
> So i should not have mod key in my resourse file(.app
> file)
> Then how do i specify start function of my application
>
> with out using mod key
>
> Starting Applications
> ---------------------
> A primary application can be started in one or two
> steps. The first step is mandatory and the purpose of
> it is to start the main supervisor of the application
> and possible permanent children. The second step is
> optional and its purpose is to synchronize processes
> within an application.
>
> Thanking u sir
>
> regards
> suresh s
>  --- Wiger Ulf <ulf.wiger@REDACTED> wrote: > The part
> of the OTP documentation that describes
> > behaviours is:
> >
> >
> http://www.erlang.org/doc/r9b/doc/design_principles/des_princ.html#1.1
> >
> > If you want to make a fault tolerant application,
> > the supervisor behaviour
> > is an essential component. The above document also
> > talks about building
> > supervision trees. The reference manual for the
> > 'supervisor' module (part of
> > stdlib) is also important.
> >
> > One of the most common behaviours is gen_server, the
> > generic client-server
> > behaviour.
> > Here's a slightly simplified version of gen_server.
> > Perhaps it will clarify
> > how the callbacks are used. It lacks a few of the
> > gen_server features (see
> > erl -man gen_server), but behaves essentially like
> > gen_server does.
>
>
> ________________________________________________________________________
> Missed your favourite TV serial last night? Try the new, Yahoo! TV.
>        visit http://in.tv.yahoo.com




More information about the erlang-questions mailing list