[erlang-questions] Applications, supervisors, and servers, oh my

[David Welton]

On Tue, May 25, 2010 at 1:03 AM, Bernard Duggan <bernie@REDACTED> wrote:
> On 24/05/2010 10:28 PM, David Welton wrote:
>> 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).

> It being an 'application' does not inherently limit your interactions
> with it.  Mnesia, for example, is an application and nobody would
> suggest you can't interact with it.  For example, you can still talk to
> any registered processes within that application using their name.  All
> (well, not all, but for the purposes of this discussion) an application
> provides is a way to start/stop a defined set of processes.  If you want
> them to be supervised, the application in turn needs to start the worker
> processes within a supervisor - applications themselves don't provide
> any fault tolerance.

Thanks, this helps some.  I suppose registering the process names with
a value the user supplies is the best way of giving them a way to
continue interacting with the system once it's been started.

In a similar vein, I'm wondering about the architecture of some other
code I'm using.  I found this on the net, and started adapting it:

http://github.com/davidw/erlang_twitter/blob/master/src/twitter_stream.erl

It basically just utilizes the http streaming API and then hands off
received chunks to a user supplied M/F/A.

However, I'm wondering about how to handle errors.  The code, as is,
has all it needs to deal with pretty much any error.

"If it ain't broke, don't fix it", but I'm curious if this sort of
thing might be written in a more OTP style, and if so, how.  For
instance, in addition to real errors such as 'the network went down',
there are also errors like authorization problems.  The first requires
that it be restarted, the second really should just fail all the way
up, so that whoever can go in and give it a correct user/pass.  The
current system seems more fine-grained than what a supervisor could
provide, or am I wrong?

Thanks,
-- 
David N. Welton

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

http://www.dedasys.com/