Events Subscriptions / Notifications sub-system

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Stage = Conceptual

See Old Events API for basic Events API.

Comments appreciated (See also: Messaging_2.0)

Overview

As part of the CM initiative, we are defining, designing and building an event/subscription/delivery layer for Moodle. This extension will allow for the definition of specific events (using the current Moodle event system) that can be tracked and acted on. A subscription layer will allow users to pick events that they wish to subscribe to and be notified about. A delivery layer will allow for them to choose their preferred method(s) of delivery - email, web, RSS, IM/SMS, Facebook, Twitter, etc.

An example would be selecting an online assignment event for a particular course. I could the subscribe to it and select SMS as my delivery mechanism. When an event occurs (a student submits an assignment), I would receive a message via my selected mechanism (SMS) at the device I use for this service. This message could include the content of the assignment submitted, if that is how that subscription is defined.

Components

Event System

Moodle currently supports events through the events API (/lib/eventslib.php) and the three 'events_' tables. Particular events that can be handled are identified by an entry in the 'mdl_events_handlers' table using the 'eventname' field. We would like to hook into this system so that certain events can trigger a subscription/delivery layer. With the current system, this would be done through the events handlers tables. Consider adding another definition layer and table that defines the events that exist and keeps information about what types of events they are. Then, certain events could be marked as eligible for subscription.

Further, explore the possibility of defining event generators. These would be Moodle element instances defined as providing specific event types. For example, an event type would be a 'Forum post'. An event generator would be specific forum instance or even a specific forum discussion. If a discussion defines itself as an event generator, it can be available to be subscribed to.

These event types and generators would be defined by the elements that handle and generate them. Much like the current system, a plug-in 'events.php' file would define all of the necessary information, and would be handled by the Moodle install system. The elements themselves would be responsible to provide the event generators.

Subscription System

Provides the API's and interfaces to allow users to select the event generators they would like to subscribe to, and the delivery mechanism for which to receive the subscription. Delivery mechanisms would require another type of plug-in (see below) and would have to be registered as available for each type of generator.

Examples of this include: - Login failure event - SMS (send all login falures to my defined SMS) - Assignment Instance Submission - Twitter (send a tweet with information on the submission)...

Delivery System

Specific delivery mechanisms can be defined that provide the necessary elements to allow users to choose their preferred delivery for specific event generator subscriptions. As a minimum these would include web-based, email and RSS. But other systems could add the mechanisms by providing the necessary plug-ins.

The delivery system runs as a separate application to the Moodle app, and acts on the events and subscriptions defined.

This needs to be combined with the existing messaging system initiative. In particular, use the same messaging API. Also, review the original plans. They are more in line with what we are proposing.

Issues to Deal With

Scalability

The delivery system should be best built as a subsystem that could be removed from the same system as the Moodle application. In that way, it can run without interfering with the main Moodle site. This would allow it to work with separate email systems, SMS gateways, etc. The connection point would still be the database tables, so though should be given to optimizing this connection such that operation of the delivery system does not tie up the database. This could be done simply by generating only one event in the events system, and have a subscription handler act on that. This could use the queue and send the event info to the subsystem. If the subsystem has all the other information, then it can remain separate.

Legacy Code

Initially, we would need to build our own transport layers for elements that don't use the system, or modify the elements ourselves to do this. If the first, it would need to be a cron task (or something) that scoured the element for data that would have caused such an event, and then fire the new API's. In particular, when event generators no longer exist, clean up must happen.

UI

Come up with a user-friendly system that shows all possible subscriptions to a user, and allows them to manage them in an easy way.