Applications, supervisors and supervisors, oh my

[David Welton]

Hi,

For fun, I've been fooling around with this code:

http://github.com/gdamjan/erlang-irc-bot

To try and get back in the swing of Erlang.

It's pretty good code, and the author is available on #erlang to talk
about it.  He's got some of the same questions as I do, so I thought
I'd try and summarize what I'm wondering about.

The API works like this:

    {ok, [{connection, Settings}]} = file:consult("settings.cfg"),
    {ok, IrcBot} = ircbot_server:start_link(Settings),
    gen_server:call(IrcBot, connect),
    gen_server:call(IrcBot, {add_plugin, plugins.twitter, []}),

Which loads up some settings, starts the gen_server, connects it to
the network, and then loads a plugin.  So far so good.

What I'm wondering is if this should be an "application".  I want it
to be restarted if it dies, so adding a supervisor makes sense.  I'm
not quite sure where applications fit in in terms of API's though...
many that I've seen don't present much of an API, though: start/stop,
and not a lot of ways of interacting with whatever's under the hood
(or so it seems, perhaps I'm mistaken).

The author of that code has added an application layer on top of it,
and it seems to work that way too, which seems to limit the potential
of the code if you want to include it in another application.

I also want to be able to start up whatever I have created with
-detached -s .... and not have to fiddle with it a bunch.

I guess I'm looking for some thoughts/guidance on Erlang API design.
I've looked through some of the online docs and the relevant bits of
Francesco's book, but am still not entirely sure what the "best
practices" in a case like this may be.

Thank you,
-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/