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)