On 24.02.2005 12:04 -0500, Jesse Guardiani wrote:

> Python *might* possibly be slower, but also easier to read than
> PHP, IMO. I think Perl would probably bring the same speed or
> better, but with much ugliness.

One reason why I chose PHP over Perl or Python was also the fact that
all you need to run PHP the way m0n0wall uses it is one single ~1 MB
binary. No big libraries, nothing. Another reason was that I simply
know PHP much better than I know Perl.

PHP would be fast enough for our application; the disadvantage with
the current solution (PHP being used as a CGI) is the overhead of
starting it up for every request (which shows on slow embedded
platforms like net45xx). I haven't found a small, reasonably secure
web server that does HTTPS and provides a native PHP SAPI. There are
patches for thttpd, and in fact I started with those in the very
first m0n0wall versions, but there were serious problems with them
(one of them being that all PHP scripts had to run serially, which
created performance issues), plus you had to keep two copies of PHP
around (one in thttpd and one for the rc scripts).

> Personally, I'm not so interested in the speed aspect of OCaml for
> a webGUI. I think the current PHP speed is fine. I'm more interested
> in the security aspect and reliability that OCaml offers. OCaml is

Can't speak about the reliability, but the security aspect isn't that
important in m0n0wall, as odd as it may sound. PHP is really only
used as a better macro processor to put together the configs that the
various subsystems (ipfilter, ipfw, userland daemons, ...) need.
During normal operation, no PHP scripts run at all (only when the
webGUI is being used or on special occasions like when the WAN IP
address changes).

If I'd have to completely reinvent m0n0wall, I think I'd chose an
architecture where there is always one monolithic "server" component
running that manages external events, controls, configures and
monitors the various subsystems and accepts configuration changes
over TCP connections. That way it could be managed with different
means (web interface, CLI, native Windows application, ...). However,
the current scheme works well enough that I don't see strong reasons
for reinventing the wheel.

- Manuel