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