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.
> 
> OK, that's probably not very likely, but it
> is something to be aware of.  I know, for example,
> that I have been in situations, like DR testing,
> where WAN was not available.

Hmm, I can see your point here. What about meeting in the middle: The 
help pages relating to basic/initial setup (specifically what is 
needed for a newbie to get from a "blank" m0n0wall to a working WAN 
interface) could be in the m0n0wall image (with only a few lo-res 
images, if any), everything else could be on the server. In a very 
fancy scenario, the "built-in" help pages would only be used when the 
server wasn't accessible, otherwise better, more elaborate and 
possibly image-rich versions from the server would be shown.


> Other than that, it's a good idea, following the same
> idea as the captive portal being an external page

Huh? Is the captive portal page(s) external? I thought they were 
uploaded and stored on the CF? (Would be great with both options 
though, not that it should be too hard to manually make a small 
"strap" page that loads an external page by script or meta-refresh.)


Regards,

Adam.