Fred Wright wrote:
> On Fri, 28 May 2004, Seth Rothenberg wrote:
> 
> 
>>>>Or does that start to be bloat,
>>>>excessive complexity, and totally
>>>>unneeded?
>>>
>>>Some people are bound to think so. Thus I'd like to suggest a solution
>>>that should prevent most, if not all, the "bloat":
>>>
>>>Couldn't such context-sensitive help consist mainly of externally
>>>linked pages?
>>
>>The concern I have with that is, that assumes that
>>we succeeded in setting up WAN and that WAN is working.
>>If WAN went down and we were trying to configure
>>the backup, help out on the WAN wouldn't help.
> 
> 
> Yes, not to mention the unpredictable delays in accessing documentation
> from outside sources.

Huh, "unpredictable delays"? Are you talking about the usual internet 
latency here or what? I have several apps which will show some 
internet page when I access its help pages (such as Thunderbird), and 
of course there will be a short delay, but I can't see that this would 
be a problem? (At least not how it would be a larger problem than it 
is now, where ALL the m0n0wall documentation has to be fetched from 
the internet.)


> It's unlikely that any platform used to host m0n0wall is too tight for
> space to allow built-in documentation, as long as it's not part of the RAM
> disk.  Even spinning up a CD to read a help page isn't that bad, and
> reading it from CF is no problem at all.

Of course, if there is no objections, it would be preferable to have 
such m0n0wall "context help" on the CF. I'd personally prefer that it 
be loaded into RAM though, like the rest of m0n0walls GUI, but I can 
understand how that would be a problem on low-RAM embedded 
implementations (and perhaps it is too much ado for a simple help 
system to check for RAM availablity and only upload if there's enough 
of it?)

Anyway, I just wanted to point out that, IF there were objections to 
such "bloating" of the m0n0wall CF image, an alternative was available.


Adam.