Manuel Kasper wrote:

> 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.

That's a neat idea. Lots of advantages! webGUI wouldn't even have to
run on the m0n0wall.

Do you think you'd still use PHP for the server component?

-- 
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v)  423-559-5145 (f)
http://www.wingnet.net