Scheduling subsystems (crontab, at) and the desktop

[Rodrigo Moya]

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. 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.
> 
> 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.
> 
I would also suggest you just write code to deal with the differences in
the cron/at commands in UNIX versions. As Rodney says, there are very
large and old UNIX installations, and having all those UNIX versions to
come up with a standard in their commands is like asking for a miracle
IMO.

In gnome-nettool we had a similar problem, because we capture the output
of commands like ping, traceroute, etc, which are also different. You
can do something similar, by writing wrapper code that deals with each
individual cron/at implementation.

cheers