[ previous ] [ next ] [ threads ]
 From:  "Bart Smit" <bit at pipe dot nl>
 To:  "Manuel Kasper" <mk at neon1 dot net>
 Cc:  "Eric Appelboom" <eric at mweb dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Group objects
 Date:  Tue, 20 Jan 2004 13:36:04 +0100 (CET)
Manuel Kasper said (about grouping objects):

> This has been discussed before - it will be done when ipfilter 4.0 is
> released

I think this is touching a rather fundamental design issue in
m0n0wall. The way m0n0wall is built now, it is actually a graphical
shell around basic mechanisms and utilities present in the underlying
platform. It does not really present the end user with a model of its
own, but interfaces with the working models of the underlying layers.
So, to be able to understand m0n0wall, you still have to understand
the underlying layers and their working models, *plus* the way the
m0n0wall webgui is tied to them.

Yet, this fact is not made explicit in the webgui or the docs. The
webgui even hides much of the detail, and by doing so, lures you into
thinking that you don't need it.

I feel this is sometimes a bit shizophrenic, and makes m0n0wall harder
to understand than would be necessary. If you try to view the m0n0wall
functionality on a higher level, you'll find some pieces missing for
full understanding. And if you're working with the concepts of the raw
stuff underneath, you'll sooner or later need to talk directly to
these layers (for which the webgui provides no hooks).

Mind you, I'm very impressed with the quality of the m0n0wall GUI in
general, and Manuel clearly has a great talent for doing UIs, but in
order for m0n0wall to become big (both in functionality and installed
base), it may become necessary to define a good model for m0n0wall's
functionality and implement that on top of ipfw, ipfilter and what
not, as opposed to letting the bottom layer directly dictate the
concepts that the user sees.

Preferably such a model would give the user a clear picture of the
topology of network interfaces and filtering rulesets ("exactly where
are these rules applied?") and will make it possible to simply
visualize processing order. "Object grouping" could be part of it as
well. These probably have even greater usability than the native
"aliases" of ipfilter 4.0, as these are necessarily ipfilter aliases,
and not m0n0wall aliases.

Yet another 2 of my cents....