On 11 January 2012 15:11, Gregg Wonderly <gr...@wonderly.org> wrote: > On 1/11/2012 8:30 AM, Dennis Reedy wrote: >> >> On Jan 11, 2012, at 920AM, Dan Creswell wrote: >>> >>> Alright, so what am I talking about? Convention over configuration - >>> and there isn't enough of that in the starter kit. >> >> Excellent point. >> >> >>> Once the common >>> cases are taken care of, configuration becomes more of an exception >>> than the rule and then there is motivation to dig deeper and do >>> something more serious like use Groovy or whatever on the behalf of >>> the individual that will help them get over the hill to something >>> working. >>> >>> Simple cases? Maybe two boxes on the same LAN (thus one can use the >>> subnet as a group name and make some reasonable assumptions about >>> multicast) and maybe a single box with a correctly configured local >>> loopback. >> >> Maybe: >> >> groups - default to user.name >> multicast - assume available (warn if not) > > > To whit, the simple webserver tries to connect to itself at startup and > announces if it can't. It might be interesting if Reggie issued a unicast > to itself on local host, as well as expecting itself to appear on multicast > discovery (maybe it does and I've forgotten about this), and announcing if > it can't, at least, see itself via unicast and multicast discovery. >
I would imagine it's possible to put all these checks in a little tool that runs ahead of everything else at install time (and maybe when starting things in general or similar). After all, the reason for these checks is to assist in diagnosing a problem that has occurred. Better to do all these tests and checks from one place before a problem occurs and confuses people.
