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
> running.
> 
> 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
> that!)
> 
> cheers, michael

Hi,

I can certainly understand why one wouldn't choose to serve files from 
the m0n0walls mentioned above. And I too respect Manuels "purity" 
credo. But...

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


Regards,

Adam.


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