Re: [Clockwork-developers] Architecture of job scheduler

[Shawn M. <smc...@ei...>]

This one time, at band camp, Joel Loudermilk wrote:
>=20
> I don't know exactly how this works, since I've never used their schedule=
r,
> but it's interesting. What's also interesting is that on their web site, =
they
> mention this only to say that if a system is isolated from the network,
> it will still run its jobs. I don't know about you, but if one of my syst=
ems
> was isolated from the network, I think I would prefer that it not attempt
> to run any jobs, since they most likely wouldn't work.

Another concern would be clocks; it's easier to keep one machine synced
than dozens.

Another would be stopping a job from running; what if the machine on
the other end is too busy to listen to you?

However, I don't know that these are insoluble problems.  For instance,
the "client" end could check with a central time server(s) before running
a job, and be configurable as to whether or not it cared if it couldn't
see it.  If you made that configurable per-job, you could actually remove
cron, instead of just supplementing it.

> event processor (to borrow a term from AutoSys). And a SQL-based database
> would make things easier to work with from a development perspective, but
> not until now did I realize that it might make the system less attractive
> for a user, since they would have to manage another database.

No reason we can't make the database a part of the server program, and
not use a full-blown SQL, is there?