Fred Wright wrote:
> On Fri, 28 May 2004, Seth Rothenberg wrote:
>>>>Or does that start to be bloat,
>>>>excessive complexity, and totally
>>>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
>>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
> 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
Anyway, I just wanted to point out that, IF there were objections to
such "bloating" of the m0n0wall CF image, an alternative was available.