Hi Ken,

Ken Hornstein wrote:
> 
> >Well, to jump into this discussion: my point is, that names
> >don't make it clear if the transition is to the state or from
> >the state. Will the battery script be run when we go into
> >the state, or when we leave the state?
> 
> It was pointed out to me that _all_ of those apm scripts are implicitly
> understood to be "to" script.  For example, standby, suspend, and resume
> are all scripts run when _entering_ that state.  So line and battery
> continue that trend.

Then be it so :-)

> >Maybe we call the scripts with parameters like the SYS V rc?.d
> >scripts:
> >battery start when we enter battery state
> >battery stop when we leave the battery state
> 
> I'm not sure rc.d works so well here.  That's nice when you have a bunch
> of independent "modules", but for things like states which are exclusive

That's not correct. The rc.d mechanism is supposed to solve problems
of modules that do depend on each other. That's what the enumeration
is good for. You know some scripts will have been executed (and thus
established a certain service), before others will run. And you have
clear notion of which services are going to be started and stopped in
which runlevel. But let's not make this into a general discussion
about SYS V runlevels and rc.d scripts, see below ...

> (you aren't ever going to do "battery stop" without also doing a "line
> start"), I'm not sure it's needed.

That's true, but if you add more states, like the aformentioned 
"battery low", or even "power if going down"/"power is coming back up
again"
the transitions might become more complicated. But, on the other hand, I
think you are right, that the mechanism of rc.d is overkill for this
situation.

Have a nice weekend (and week, I am leaving now for some business
travelling)

  Guenther