I’ve been working on the design for what are called distribution jobs and alerts in Bricolage 1.x. There were some good ideas there. Distribution jobs enable users to set up a list of tasks to execute against the files being distributed, such as validating them against a DTD or distributing them via email. It also allowed developers to create fairly simple plugin modules that could be added as new jobs. Alerts are great ways of letting users know that some even has happened, and their rules-based evaluation of event attributes is a powerful way of configuring alerts to be sent only for certain events logged for certain objects.

The problem is that they’re specific solutions to general problems. Distribution job s are an example of scheduling arbitrary tasks to be executed, while alerts are an example of triggering the execution of arbitrary tasks upon the logging of an event. So what I’ve been working on is trying to generalize these ideas into a simpler yet more powerful and flexible architecture. What I’ve come with is this:

Tasks

Very simply, a task is an object of a class designed to perform a simple, um task. Examples include publishing a document, expiring a document, sending an alert, or validating a file against a DTD. An abstract base class, Bricolage::Biz::Task, will establish the the interface for tasks, although its subclasses may add their own attributes (such as the subject and message of an alert). Each will implement an execute() method that will simply carry out the task on the object passed to it. Some task classes may operate on only one type of object (such as Task::Publish), while others may operate on many or even all Bricolage business classes (such as Task::SendAlert). There is no connection between task classes and events or jobs, except that the object that called the task object’s execute() method will be passed to execute() as a second argument.

Actions

An action is an event-triggered series of tasks. New action types can be created that have rules set to be evaluated against the event, just as is currently the case for alert types in Bricolage 1.x. The difference is that rather than being limited to sending alerts, actions types will be associated with one or more task objects, and each of those tasks will be executed in sequence when an action of that type is triggered. This will enable users to, for example, configure an action to republish an index document whenever a story document is published.

Jobs

A job is a scheduled series of tasks. Users will be able to create new jobs for any single object in Bricolage, associate any number of task objects, and then schedule the job to be run at some specific date and time in the future. This approach will enable users to, for example, schedule a job to send an alert about a given document one year in the future, as a reminder to update the document.

Destinations

Destinations will be similar to what’s currently in Bricolage 1.x. However, rather than having “job” classes specific to distribution, they’ll be able to specify a list of any tasks that are designed to be executed against an output file. This keeps the interface for tasks identical across all three uses.

Alerts

Alerts are no longer closely tied to events, since they can sent as part of a scheduled job or as part of a distribution to a destination in addition to when an event is logged. Rather, they will only be created by Bricolage::Biz::Task::SendAlert. So a Bricolage business object can have any number of associated alerts, just as it can have any number of associated events.

Upshot

The upshot of this redesign, which took me several days of thinking to tease out to be general enough to satisfy me, is that more users will have more of what they need from Bricolage, and developers can more easily add new functionality that’s immediately available to event actions, scheduled jobs, and distribution destinations.

Looking for the comments? Try the old layout.