[gnome-schedule-devel] Re: Scheduling subsystems (crontab, at) and the desktop

[Philip Van Hoof]

On Thu, 2004-07-22 at 08:21 -0400, Rodney Dawes wrote:
> Hrmm. Scheduling for the user is something that would be nice to have
> integrated into the user's calendar I think. And having a cron daemon
> that read scheduling information from an icalendar file, where "tasks"
> are used to specify what applications to run/etc...
> 
> Are you suggesting that a spec be created for the data storage format?
> The command line options to the various cron tools? What exactly? It
> seems to me that saying "use icalendar" would be good. 

Whats needed is a standard for the daemons at and crontab. Perhaps a way
to know exactly when the configuration has been altered (much like gconf
or perhaps using fam).

For at a simple delimiter character between your own script and the
stack of environment variables that will be prepended to your at-record
would suffice.

For crontab the only problem we have is the fact that we have found
multiple crontab implementations. Each of them have other options.
Luckily the crontab-format appears to be the same.

For scheduling systems like anacron we have not yet created a GUI.

Integration with the calendar would be nice but could also confuse
users. A user who does not understand the difference between a task that
the computer will launch and a task that he will have to perform -
because it's calendar tells him or her to do that-, might get confused.
This could also make it more hard for users to maintain a calendar for
their own personal use.

It would be nice to have a little icon on the calendar of for example
evolution. Once you go over that little icon a hint could show the user
information about what the crontab or what at is planning to perform at
that moment in future.

Note that a simple record in crontab: * * * * command, would put such an
icon on the evolution calendar, 60 times per hour-block.

Nevertheless is also that programmatically solvable and it doesn't mean
that nobody should try integrating them.


You could also set a crontab that will launch each minute, which will
read all the iCalendar files for possible tasks to execute. I fear,
however, that this adds yet another layer of abstraction to the system
scheduling. It would make it harder for the maintainer of the desktop
computer to know what task will run and when.


> Though, we run
> into the backward compatibility problems. And we all know that admins
> are different from users, and are more often the people that are
> actually doing scheduling. Users don't tend to do backups. Trust me
> here. I have repaired many a windows machine, where the users lost that
> very important piece of data, simply because they don't back up. Backups
> take a lot of time. They require more manual intervention on desktop
> machines. And really, what kind of media are you going to back up 200 GB
> onto? Tape? How many desktop PCs come with tape backup media? A CD-R
> holds 700 MB. Virus scanning is probably more important, but the virus
> scanner will probably install its own cron job to scan the system, no?
> Telling xmms to start playing every day at 7 am though. That's probably
> something more useful. At least, that's how my alarm clock is set up.

Okay, the UI that we are creating here, however, is not responsible of
creating such backups. It would be responsible for maintaining the
application (crontab or at) that will do the launching of the
application that would be responsible.

> I'm not sure we want to try and enforce something upon system services
> from freedesktop.org yet. We can't just go break compatibility and
> everything there. There are very large unix installations that are still
> many years old, where they may update the UI, but not the backend.



 
-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: Philip dot VanHoof at Cronos dot Be
http://www.freax.be, http://www.freax.eu.org