Engineering

Fibers-based Timing

This package uses Meteor.setInterval and Meteor.setTimer. While the idea of timeouts on a server may not sound like a good idea - it may actually be the right approach because the Meteor's timing functions are automatically bound with-in a fiber.

MongoDB Indexing

Steve Jobs will create the following collections:

• jobs_config for configuration data, which mainly revolves around figuring out which server should be running the jobs.
• jobs_data for jobs data, which includes everything a job needs to run.

The jobs_data collection is indexed on the due and state fields for optimal read performance.

Timing and Timezones

This package will use the servers time and timezone to base all of its operations, and all time functions are relative to that. This should ensure that jobs run predictably (i.e. ru this job in 30 minutes). If timezone is of importance, you can set it manually in Meteor with the TZ environment variable.

Server-Side Only

The Jobs is designed to be minimal and works server-side only. However, you could make its data accessible on the client using Method's or Pub/Sub. For example:

// client
Jobs = new Mongo.Collection('jobs_data');
Meteor.subscribe("jobs")

// server
Meteor.publish("jobs", function () {
	return Jobs.collection.find();
})

You can also write Method's to make it easy to create your own jobs from the client:

// server
Meteor.methods({
	'addJob': function () {
		args = Array.prototype.slice.call(arguments);
		job = Jobs.add.apply(null, args)
		return job;
	}
})

// client
AddJob = function () {
	args = Array.prototype.slice.call(arguments);
	args.unshift("addJob")
	Meteor.call.apply(null, args);
}

Note: these are untested examples, and they are not secure at all