Michael Mee wrote:
> One of the most compelling arguments I've heard, and respect, for not
> allowing image files (or other files to be served via http) was this:
> The config.xml file contains *everything* needed to get m0n0wall
> There's many things to like about m0n0wall, but this particular feature
> often gets overlooked. As someone who now (unexpectedly!) manages several
> boxes, this is a wonderful, wonderful feature. It makes backups simple. It
> makes restores a breeze. It makes 'firmware' upgrades practical. IMO, its
> one of the best features of m0n0wall. (I also manage several boxes running
> pebble, and I pray I never have to rebuild one of those... and I also dread
> having to upgrade them)
> I respect Manuel's desire for 'purity' with this particular design choice.
> (Hmm, that said, is there some way of storing binary files in XML that isn't
> too ugly as a little gif sure would be nice .... no, no, I didn't say
> cheers, michael
I can certainly understand why one wouldn't choose to serve files from
the m0n0walls mentioned above. And I too respect Manuels "purity"
... What are the arguments for "not allowing" others to do so? What is
the "impurity" that this would introduce?
I mean, it isn't as if anything new would have to be added to
m0n0wall, nor would there be any kind of security or overhead
problems. In fact I can't see that anything at all would change for a
user choosing not to serve any files in this manner?
Please explain to me what I'm missing here?
P.S. About binary files in XML: I'm not aware of a standardized way of
doing this (as in "part of the XML standard"), but I guess a simple UU
encoding or similar would do the trick? (Nice idea by the way, even if
it could be said to be a bit "dirty".)