Re: soliciting opinions about potential new cron/at features.

[Rob Browning <rlb@cs.utexas.edu>]

Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:

>  b) It makes cron/at use incompatible features that other flaws of
>     Unices and Linux doesn't have.  Hmm, thinking of this, Linux has
>     many features which other Unices doesn't have.  Not a good argument
>     though.
>
>  c) Re GnuCash: This would make GnuCash depend on a certain distribution
>     and certain version of cron/at.  I don't think that this would
>     be soooo useful.

Considering both points in reverse order.

(b) That's OK.  The feature would be optional, only available on
systems where GnuCash detects a suitable cron (or at).  On other
systems, the scheduling code just wouldn't be available (or would be
substantially less sophisticated).  Basically, I'd much rather enhance
cron/at (if people would allow it) than to hack up some mechanism into
GnuCash (using substantially more code) which isn't nearly as elegant
or robust.

(a) This is OK too (though I'd obviously prefer a solution that was as
"elegant" that didn't require this).  Most who are able to install
GnuCash on their system will also probably be able to install an
updated cron/at (or do without the fancy scheduling features).
GnuCash already requires ePerl, guile, slib, lesstif (or eventually
gnome), and swig.  I'd prefer to not require people to install an
updated cron/at, but I think it really would be a nice solution, and I
can't think of a better way to handle this that wouldn't require a
per-user daemon (or a system daemon parallel to cron [1]) that would
have to be kept running (even when the user wasn't logged in), and
making sure that happens correctly across shell implementations and
systems is just a waste of effort.

I guess one of my main questions is "if I write the new cron code (and
do a reasonable job), would it be likely to be rejected?"

Thanks

[1] and why not just spend that effort enhancing cron for everyone.
The next app that comes along could also use this mechanism
(i.e. plan, gnomecal, whatever rather than hacking something up
themselves)

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930