Hi Manuel and others

> What do you think? Is it time to perform a major architectural
> overhaul on m0n0wall? Or would you rather continue with m0n0wall's
> current architecture, perhaps making small adjustments where
> necessary, and on the other hand spend more time rewriting code to
> get new features integrated?

These are my thoughts to your questions. I try to be as clear as possible,
but if there remain some questions, please drop me a note and I will try
to be more verbose.

First of all: I think the decisions you made when starting with the
current m0n0wall architecture were quite perfect. XML based configs, sleak
PHP based system. Nice.

Just to think about what the current requirements are: Everybody wants to
have feature x or y implemented. OpenVPN was something much discussed,
there were other features as well. So m0n0wall should be able to cope with
new requirements/requests. It runs on many different systems (normal PC,
soekris board, etc) which requires everything to run at the slowest and
"weakest" hardware.

To look into the future: IMHO m0n0wall could go into this direction:

- Modular sleak core system
- Management interface
- Extension framework

I'd base the whole thing on OpenBSD. Then plug some C or Java based core
management engine onto the core system. Using PHP as the web interface and
having the extensions and the possible "third party" extensions use the
same interfaces as the built in PHP UI.

Now let me explain why these decisions:

- OpenBSD is a project which lately seems to put quite an effort into
networking. I base this on the observation of pf, altq, OpenBGPD and other
nice features which OpenBSD lately (or earlier) introduced. There are some
- like djb - which state that the network implementation of OpenBSD is
either unstable or slow. I have neither seen facts nor figures proving
this. Like that m0n0wall could profit from the OpenBSD's current focus on
save networking (ICMP DoS attacks, sequence guessing, etc) and having a
redundancy enabled firewall with bgp would be cool as well. 

- Using either C or Java for the core system: C would be interesting speed
and portability wise. Java would be interesting for its speed of
development and security (overflows...), there are of course questions of
licencing with Java. And it is not true that Java is slow. Especially not
when not using Swing or another UI. But Java is a memory hog, which could
be bad for Soekris based systems.

- Having a management interface would allow the system to be either
managed locally via http or from an external source tunnelled via ssh with
whatever tool there is. The idea would be - as Manuel described earlier on
- that there is some kind of interface between the core system and the
management consoles/applications. Like that one could even think about
having SNMP support added via the same interfaces, as an idea.

- Starting with an extension framework right at the beginning of the
planning and architecture could allow us to add more features easily as
pluggable pieces. Ideal would be that I can decide to add bandwith shaping
or I can just deactivate or remove it. Cool would be something like on the
fly flash image creation where I can define my image on the m0n0wall
webpage and when I am ready I can download the personalised flash image
with only the plugins I want.

Thats a heap of ideas and would result in another heap of work. This is
meant as a bunch of ideas to have m0n0wall become something even better
than it is today and not as musts.


> Finally, something needs to be done about the development style as
> well. So far, I've coordinated all changes to m0n0wall and analyzed
> and tested most contributed patches. While I think this has resulted
> in a relatively high code quality, I'd like other talented people to
> get more involvement. Volunteers, step forward! One of the ways to
> enable this will be a common version control system for the code -
> either CVS or SVN.

CVS or SVN is definitely something which you should take into calculation.
But there will always be somebody at the end of the development chain
deciding to accepting code or to having it either refused or rewritten.

Regards,
Adrian