Nut upsdev - Mar 2008 - [nut-commits] svn commit r1348 - in trunk: . docs drivers man

Arjen de Korte wrote:
> Author: adkorte-guest
> Date: Sun Mar  2 13:20:54 2008
> New Revision: 1348
> 
> Log:
> - change 'ups.delay.start' and 'ups.delay.shutdown' to
server side variables that control the ondelay and offdelay for the
'shutdown.return' and 'shutdown.stayoff' instcmd's
> - create 'ups.timer.(start|shutdown|reboot)' that indicate the time
before these respective timers elapse (read-only)
> - remove the test for ondelay>offdelay (the values can be changed at
runtime too and for some devices we already know there may be legitimate reasons
for doing so)
I believe this puts an end to our misery with regard to the shutdown
functionality of the usbhid-ups driver. I have tested this on the MGE
Evolution 650, developers with access to other machines are encouraged
to try this out on theirs.

One thing that is still open to debate, is how long DEFAULT_ONDELAY and
DEFAULT_OFFDELAY should be. Peter Selinger has raised some good
arguments for lowering DEFAULT_OFFDELAY. I feel that he is right and
that we should lower this value (maybe to 1 second, so that devices that
only act upon the change from 1->0 will work by default).

The only problem to this, is that some people (most notably the MGE
users) may expect that the driver will allow for a 20 second grace
period by default. In that case, they may be in for a nasty surprise if
we lower this value. On the other hand, the driver will now clearly
indicate what kind of delay they can expect upon shutdown, so they have
been warned. None of the other drivers supported a shutdown with delay
function before nut-2.2.1 by the way, which mitigates the problem even
further.

Therefor I raise the question, should we lower DEFAULT_OFFDELAY to 1?

Best regards, Arjen