0.6 - The Cron: Is it that time already?

Submitted by Trispis on Fri, 2006-09-15 14:43

This page replaces the section of the Manifesto called "UTILITIES". Somewhere on this site is a post I made about the cron; and, since I have code written for the core and the cron, I've decided to relegate the remaining previously-documented piece (the Debug Zone) to a potential contributor module.

You can read my whole ITBG Presentation for a philosophical history of this module. I've included the currently pertinant points here. The URL's referenced below can be retrieved from www.archive.org, if you really need to see them.

We need an optimized cron. Something which provides maximum potential to both the core, and the game in general. Yet which also must be inter-connected with a registry (a MU* portions maintenance and accounting widget).

Are there cron systems available? Of course. Myrddin has a nice one. Raevnos wrote a pretty nifty one for M*U*S*H a couple years ago which even uses an internal registry. So why not use one of these? Especially Raev's... which superficially appears almost to have been written specifically for the warpedcore design (described above) ??? why not? Raev's a good guy,... surely he'd be open to some sort of contribution negotiation...

But wait...

Javelin implemented a cron of a wholly different type on M*U*S*H. A chat channel broadcast based cron. Objects can connect to this channel and listen for the various and sundry broadcasts. Jav's also has a very intrigunig side-effect -- systems using the cron all happen to be conveniently connected to a specific chat channel -- or, phrased a bit more organically: objects using the cron have created a sort of registry of their own via the cwho() function.

Raev's has an added benefit of having objects registered in various 'intervals', but Jav's is a simpler implementation which doesn't need any maintenance after a purge.

Jav's can also be easily extended to do broadcasts as frequently as once a minute, (Jav's currently is only once an hour) without any noticable increase in overhead or workload (even more frequently, if you're careful).

A channel based system could be expanded to have multiple channels for the various frequencies (hourly, 2hourly, whatever). Plus, channels for other broadcasts (core system messages, if such a need arises, perhaps?). But is channel proliferation desireable? probably not.

But, a channel based system does allow for a significantly larger amount of information to be broadcast each 'tick'.

Jav's version does multiple emits for hours which fit multiple categories. For example...

  <-Clock-> HOURLY: Wed Oct 22 20:00:04 2003 
  <-Clock-> HOUR20: Wed Oct 22 20:00:04 2003 
  <-Clock-> FOURHOURLY: Wed Oct 22 20:00:06 2003

like that. This isn't bad on an hourly basis. But if broadcasts were every minute, the ticks on the hour would be hugely spammy... especially if a wider variety of less frequent intervals were included (5min, 10min, etc.)

So, I played around with the channel concept and came up with some modifications and enhancements.

First, I dabbled with a bit-based system which uses 1's and 0's to indicate whether or not a given broadcast tick was a member of the various intervals (daily, 12hourly, 8hourly, 6hourly, 4hourly 3hourly, 2hourly, hourly, 30m, 20m, 15m, 10m, 5m).


The objections to this mainly pertained to the fact that a bit-based system (strings of 1's and 0's) isn't conducive to human implementation.

So, I dabbled with another version using an alphanumeric (more 'human readable') implementation, using the same intervals.


They each have their advantages.

The alphanumeric would be easier to document/explain in a help file, and easier for most folks to get adjusted to using.

But the one with bits allows you to do a few things the other doesn't, such as listen for 5m intervals that AREN'T also 15m intervals (*0?1).

So, I combined them and added a snippet of code which tells you the number of the weekday (3rd Monday in October, for example)...


The only questions I haven't investigated too deeply so far are:

  • Which timestring to include (local or utc)?
  • Is it desirable or necessary to broadcast both local time and utc time?
  • Do 8 (or whatever) hour crons happen at 00:00:00: local time or UTC time if I'm in tz -5?

Nonetheless, this particular cron design appears to fulfill the core's needs quite nicely... flexibly... thoroughly... efficiently.