Re: Time & CmdSchedule

[Jason Pincin <chardros@linuxkb.org>]

> First, stupid me didn't make sure NTP started last time Vodka got
> rebooted.  Hence it was a little over an hour behind (daylight savings).

Good job Aaron!  :)

> Also (and this is mostly for Jason, but anyone can chime in), I noticed
> that you created the scheduling system very cron like.  Not being a cron
> expert, I wondered what happens for something like:
> 01 01 2 * sun 
> Now, Dec 2, 1999 is today (ie, not Sunday) and yet this cronjob would of
> executed today (imperical evidence).  I thought that this was kinda
> strange: Run on the second of each month and every Sunday at 1:01am.
> So how do you want CmdSchedule.pl to act?  Like cron or different?  Will

Hm.  So CRON does sumthin like an "or" eh?  I wasn't aware of that, but I was thinking that the CmdSchedule
system operate more like "and"-style, meaning all the fields had to match.  Unless you or anyone else thinks
there is good reason for our purposes to make this "or"-style.

> your PHP tools allow someone to do that?  Is your PHP tool to manage the
> table going to do bounds checking (Feb 31st for example)?  Jason, do you

Yes, it'll do bounds checking.  You don't have to worry about that.

> really have time for this, or should it be delegated to someone else?

Well, you might be overestimating what I'm doing :), and might be thinking of CmdSchedule differently than I.
I'm not creating ANY web forms for this.  I'm leaving that up to other people.  The only thing I'm creating
right now, are the DB's (done with perhaps minor mods coming), and a PHP function to add a command to it, one to
modify an existing entry, and one to remove.  3 functions is all.

I assume someone will want to create some type of admin form using these functions to allow admins to manually
examine and control the scheduling system... but that's not the primary purpose of the table in my mind.  The
primary purpose was to allow lower level things to easily interact with the system in ways external to PHP.  So
if someone was creating a page that they would like to have email confirmations sent off for... (which may be
common), someone will make a confirmation email script for general use - design it to the specs given, and then
anyone can send confirmation emails by doin sumthin like:

<? schedule_command ("Confirm_Email", "I", ...) ?>

(I don't know the exact parameteres YET... :)  

This has the benfit of allowing us to gather usch things up and optimize how we handle them, instead of people
just coding php mailers into they're pages and having delays in page load times, etc as the system attempts to
deliver the mail and then return control to the user.  It's scheduled, handled in the backgroun, and the user
doesn't notice any extra delay.  Most of this is up to page developers... we're just laying out the foundation
here.  

It could also be used at the object level... if we add any object types that require external scripts... who
knows.  It'll definately be used in the mirroring system... list goes on..

So yes, answer to your question is "yes", I have time to do what I intend :)  I hope this clears up my
intentions for the system somewhat?  

> Also, do I need to support ranges and step values?
> 0,15,30,45 */2 2-5 * *

Yes, if you can please :)

> I also wondered about how to determine the difference between run once and
> run many jobs?
> * * * * * 
> may mean run every minute of every day or it may mean "just run next time"
> I think we should have a repeating field which is either an integer or *.
> If a * then it runs until disabled/removed.  If an integer, it runs and
> reduces the value by one.  When it reaches zero, it becomes disabled.

If you look at the CmdSchedule table, you'll see a field called CmdType.  Thats what this field was for...
"Immediate" or "Scheduled".  Any one set to "Immediate" was a run only once type thing.  It was executed, and if
succesful, removed from the table.  "Scheduled" ones stayed forever.  As you can see, Aaron's suggestion here
has MUCH more flexibility, and I like it very much.  My former "Immediate" types would just be 1's, and my
former "Scheduled" would just be *'s with Aaron's suggestion - and we would have everything in between... so we
could tell something to run 3 times, then be removed from the schedule system.  I like that!

Aaron - I'll change the CmdType field to RepeatCount and it will work just as you described... cool? (I'm
changing it now actually)

Any other Q's?  Lemme know.  Comments anyone?  


-- 
Jason
http://vodka.linuxkb.org/~chardros