[erlang-questions] a plea for cleaner modules

[Ingela Anderton Andin]

[...]

> Now, going through the list is a bit discouraging.
> The following dependencies would cause porting problems:

>   [application, dbg, error_logger]

Well it is not exactly dependent on dbg. Dbg will never be called in a normal run
of the ftp, http clients you have to give special debug flags for the dbg code to 
be run and it is mainly there for convince instead of cluttering the code with 
special debug macros doing io:format when some flag is set to true. 

When it comes to application it has to do with the bootstaping (see below) and
is not strictly necessary. 

error_logger is used to handle unexpected "should-not-happen-normally" errors.  


> Now, the bulk of ftp.erl is perfectly fine. It is, as it should be,
> just a gen_server (but why on earth is it hard-coded to run
> at low priority?!). 

I can not answer that one, typically a good thing to write a comment about, alas
whoever wrote that code did not.


> But making the module double as a supervisor
> behaviour,

There is a point in the inets processes being part of the inets
supervision tree, although for ftp the benefit is not that extensive.
In the the new start up interface for inets I am thinking of crating
a stand alone option for the start of inets services.


> and automatically bootstrapping the inets application,
> is unnecessary, I think.

Bootstrapping is also of convince reasons so that it should be easy
to test the functionality in the shell, which is appreciated by many. 


> Why not have a clean ftp gen_server module, and put all the
> gunk in a wrapper module for those who want it?
>  Even if porting to Erlhive isn't high on your list, I can think of
>  many good reasons to write the main logic in a separate
>  module, with as few dependencies as possible.

In principal I agree and I will consider it but I can not make any promises
on exact what and when changes will be done.


Regards Ingela - OTP team