Shotgun event processing framework.
Clone or download
Pull request Compare This branch is 18 commits ahead of rodeofx:master.
Latest commit 2763541 Jan 27, 2018
Failed to load latest commit information.
src Polish. Jan 26, 2018
.gitignore Setup an example config and make sure legit configs are ignored. Mar 3, 2013
LICENSE Added MIT license. Oct 29, 2010
README.mkd New README Dec 27, 2012


Shotgun Event Framework

This software was originaly developed by Patrick Boucher with support from Rodeo Fx and Oblique. It is now part of Shotgun Software's open source initiative.

This software is provided under the MIT License that can be found in the LICENSE file or at the [Open Source Initiative]( license.php) website.


When you want to access the Shotgun event stream, the preferred way to do so it to monitor the events table, get any new events, process them and repeat.

A lot of stuff is required for this process to work successfully, stuff that may not have any direct bearing on the business rules that need to be applied.

The role of the framework is to keep any tedious monitoring tasks out of the hands of the business logic implementor.

The framework is a daemon process that runs on a server and monitors the Shotgun event stream. When events are found, the daemon hands the events out to a series of registered plugins. Each plugin can process the event as it wishes.

The daemon handles:

  • Registering plugins from one or more specified paths.
  • Deactivate any crashing plugins.
  • Reloading plugins when they change on disk.
  • Monitoring the Shotgun event stream.
  • Remembering the last processed event id and any backlog.
  • Starting from the last processed event id on daemon startup.
  • Catching any connection errors.
  • Logging information to stdout, file or email as required.
  • Creating a connection to Shotgun that will be used by the callback.
  • Handing off events to registered callbacks.

A plugin handles:

  • Registering any number of callbacks into the framework.
  • Processing a single event when one is provided by the framework.

Advantages of the framework

  • Only deal with a single monitoring mechanism for all scripts, not one per script.
  • Minimize network and database load (only one monitor that supplies event to many event processing plugins).


See the GitHub Wiki.