erls | Build and manage multiple Erlang versions | FTP library

Let's rework this just a little...

First up: Naming

We don't use camelCase in Erlang. It is confusing because capitalized variable names and lower-case (or single-quoted) atoms mean different things. Also, module names must be the same as file names which causes problems on case-insensitive filesystems.

Also, we really want a better name than "server". Server can mean a lot of things in a system like this, and while the system overall may be a service written in Erlang, it doesn't necessarily mean that we can call everything inside a "server" without getting super ambiguous! That's confusing. I'm going to namespace your project as "ES" for now. So you'll have es_app and es_sup and so on. This will come in handy later when we want to start defining new modules, maybe some of them called "server" without having to write "server_server" all over the place.

Second: Input Data

Generally speaking, we would like to pass arguments to functions instead of burying literals (or worse, macro rewrites) inside of code. If we are going to have magic numbers and constants let's do our best to put them into a configuration file so that we can access them in a programmatic way, or even better, let's use them in the initial startup calls as arguments to subordinate processes so that we can rework the behavior of the system (once written) only by messing around with the startup calling functions in the main application module.

You have some options.

You can define some variables in env of .app file or in sys.config file and get them in init/1 of supervisor and return enough number of childspecs.

If count of children and other info about them come from other code and they may come in different times, you can have a child named dispatcher in supervisor, Your dispatcher's duty is getting information about starting children and starting them as child of supervisor.