[erlang-questions] a plea for cleaner modules

[Ulf Wiger]

I spent some time on the train hacking away at Erlhive.
Now that I'm able to safely handle processes, ets tables
and files (at least virtual files) inside mnesia transactions,
I thought I'd throw in a HTTP or FTP client as well.

I was disappointed to find that neither  the ftp nor the http
module are especially clean, doing just what you'd expect.

My first step in checking how much work is needed to port
something into erlhive goes something like this:

2> Beam = code:which(ftp).
"c:/Program/ERL55~1.4/lib/inets-4.7.11/ebin/ftp.beam"
4> {ok,{_,[{imports,Is}]}} = beam_lib:chunks(Beam,[imports]).
{ok,{ftp,[{imports,[{application,start,1},
                    {dbg,p,2},
                   ...]}}
5> Ms = ordsets:from_list([M || {M,_,_} <- Is]).
[application,
 dbg,
 erlang,
 error_logger,
 file,
 filename,
 ftp_progress,
 ftp_response,
 ftp_sup,
 gen_server,
 gen_tcp,
 inet,
 inet_db,
 io_lib,
 lists,
 string]

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

  [application, dbg, error_logger]

(Ok, inet_db needs to be handled too, but that's a logical step.)

None of these are needed for the ftp logic, and so I'm forced
to first cut out portions of the code. After that, it should be a
pretty clean recompile.

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?!). But making the module double as a supervisor
behaviour, and automatically bootstrapping the inets application,
is unnecessary, I think.

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.

BR,
Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070509/96e148e0/attachment.htm>