[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Tue, Feb 23, 1999 at 12:22:09AM -0600, Rob Browning wrote:
> Having GnuCash schedule an at task to handle the next job with the
> assumption that that task will schedule another task for the next
> deadline isn't really workable since if the user adds a new event that
> should happen *before* one already scheduled, there's no easy/portable
> way to remove the old one reliably -- which one is it?  Further, using
> the user's general at queue makes it all too easy for them to
> accidentally delete the GnuCash event(s) (especially since at doesn't
> allow you to label events in the at queue with a meaningful
> string...you just see numbers and times).

Ok. How's this: the user's scheduling info goes into a config file
(.whatever). There's another program that, when run, processes any
current tasks in .whatever. When it's done, it schedules another
instance of itself to run the next even (if that event doesn't have an
indication that it's been scheduled.) When you create an event, an at
job is scheduled if there are no previous events.

So you'll occasionally get a spurious process (if an event is deleted
from .whatever) -- so what? Yes, users can delete stuff (though it is
possible to view what's scheduled) but I don't know of a foolproof way
to prevent users from shooting themselves in the foot if they really
want to. Perhaps the interactive program could verify on startup that an
at job of some sort exists in the proper timeslot?

Mike Stone

Reply to: