Scheduling Abstraction Architecture

gistfile1.md

// Scheduler interface
function Scheduler () {}

// After this is called, distribution will go out to its channel on publishDate
Scheduler.prototype.schedule = function (distribution) { throw new NotImplementedError(); }

// If this is called on a scheduled distribution, the distribution will not go out
Scheduler.prototype.unschedule = function (distribution) { throw new NotImplementedError(); }


// Newscred scheduler is our standard polling mechanism
function NewscredScheduler () {}

util.inherits(NewscredScheduler, Scheduler);

NewscredScheduler.prototype.schedule = // ...

NewscredScheduler.prototype.unscheduler = // ...


// Facebook scheduler uses facebook scheduling
function FacebookScheduler () {}

util.inherits(FacebookScheduler, Scheduler);

FacebookScheduler.prototype.schedule = // ...

FacebookScheduler.prototype.unscheduler = // ...

There's two options for retrieving the correct scheduler when necessary, with and without discriminators. While discriminators allow for more traditional inheritance patterns and is preferable, I think we should first implement the option without discriminators so that we don't introduce too many changes at once. Essentially, it looks like the way we choose the publisher.

// schedulers/index.js
var schedulerMapping = {
  twitter: NewscredScheduler,
  linkedin: NewscredScheduler,
  facebook: FacebookScheduler,
  // etc...
};

module.exports.getScheduler = function (type) {
  return schedulerMapping[type];
}

With discriminators, you would just define instance methods that use the appropriate scheduler:

var TwitterDistributionSchema = {
  // ...
};

TwitterDistributionSchema.methods.schedule() {
  NewscredScheduler.schedule(this);
}

There's two code paths that need a call to schedule() on task save when the appropriate conditions are met (the publish action has been performed) and after a CMS publish (at the end of task/listener)

Note that currently facebook/traditional scheduling use divergent code paths. Traditional scheduling sets an approved flag when the publish action is performed. This makes it automatically eligible for being picked up by the scheduler. Meanwhile, facebook is sent to the facebook scheduler when the workflow is completed (rather than when the publish action is performed, which is wrong) as a post-save hook. This is done here. These have to be centralized.

The Data Model

Currently, the facebook publishDate shows the time the post will go live on the feed until it's scheduled, then it becomes the date that it's sent to facebook as a scheduled post. This is obviously inconsistent, and also requires many different parts of the app to account for this difference. publishDate should always show the time the post will go live on the feed. A different field should be used to encode the timestamp at which the post is sent to the third party site.