Core Analysis

[Craig A. Betts]

Danny wrote:
>>OK, that fixed it for Solaris.  Pretty slick plugin.  It makes more 
>>sense to me if it had a command for the on state and a seperate command 
>>for the off state.  This would allow me to use the two-state-launcher to 
>>track the state instead of my command.
> 
> 
> uh? usually tracking the state by the trigger launcher itself isn't
> enough... f. e. if the "service" started by the launcher  crashes,
> "disconnects"(pppd), or just gets terminated by some script / command,
> the state displayed in the launcher would be wrong...
> Also, what about the status when you restarted the panel / X ?
> 
> I rather went with the approach for periodically checking the status
> (every so-many seconds)...
> 
> There will be a small "tl service admin" window (callable from within
> the trigger launcher properties) where one will be able to generate the
> scripts the launcher expects for some common tasks and also to give the
> 3 commands and let it generate the script for you... but I'm still
> working on that...
> 
> If you really want "the trigger" to remember the current situation, use
> a small empty file somewhere in the filesystem / in your homedir...
> generate it in the "tl script" when "starting", check its existance when
> "checking", and remove it when "stopping" the "service"...
> 
> cheers,
>   Danny

Good point.  I didn't think about the service changing state without any 
user intervention.  Guess we all need the occasional reality check! ;-)

-- 
Craig A. Betts
IT Security Design Engineer
Arcata Associates, Inc. - Dryden Flight Research Center - NASA
Voice: (661) 276-2085     Pager: (661) 276-3038 #4010