Activity Streams

Design: Activity Stream

XWiki needs a component to record and store events happening inside the wiki. Examples of events are: create page, delete page, comment, attach etc.

Recording Events

First, we have to think about how will events be recorded. Here are two possible ways of doing this.

Using notifications

We can use the notification system already implemented in XWiki to listen to events like page creation, page modification etc. It offers a range of standard events and allows us to define custom event listeners.

PROs

• cleaner code
• separation of concerns

• recorded event types restricted by notification capabilities

Without using notifications

We can record events at the moment they occur by adding (mixing) the code needed to record the event with the code that generates the event.

PROs

• record any type of event (independent of the notification system)

• mixing concerns
• an event (like delete a page) could happened in many ways and we might end up having duplicated code or ignoring some behavior.

Event Model

An event is defined by the following questions:

• what? -> event type
• when? -> event date / time stamp
• who? -> event initiator
• where? -> event source and (where to look for) event effect

Event

• type : int
• date : java.util.Date
• initiator : String // wiki user name
• scope : String // i.e. space name, virtual wiki name or something else
• source : String // wiki page name
• data : String // free text, requested by Jerome

EventManager

• addEvent(type:int, scope:String, source:String, context:XWikiContext) : void
• addEvent(type:int, scope:String, source:String, data:String, context:XWikiContext) : void
• listEvents() : java.util.List
• listEvents(scope:String) : java.util.List
• queryEvents(sql: String) : java.util.List

• create / add
• edit
• move / rename
• delete
• comment
• attach

Event Storage

Once we have all the infos defining an event we must store it somehow. Here are two possibilities.

Low level

We can use a table, xwikievents, with the following schema:

• XWE_ID int(11)
• XWE_TYPE int(11)
• XWE_DATE datetime
• XWE_INITIATOR varchar(255)
• XWE_SCOPE varchar(255)
• XWE_SOURCE varchar(255)
• XWE_DATA varchar(255)

• simple custom query using queryEvents

• time to create the infrastructure
• not compatible with wiki replication

High level

We can store the events as objects inside a page. This way we can eliminate the scope field by storing all the events associated with a specific scope inside the same page. For instance, each space may have a page <SpaceName>.Events to hold the list of events occuring inside that space.

PROs

• infrastructure already build

• not scalable if all the events (disregarding their scope) are stored inside one single page. It's possible to store in one page per month but makes querying more complex.
• not 100% general
• complex custom queries
• generates updates in the wiki, potentially triggering wiki feeds additions, would need hidden space
• access to activity streams needs to be secured at the data level

Event Visualization

Custom (project specific)

• type -> choose the corresponding display mode
• date -> how long ago?
• user -> link to user profile
• scope -> used to select appropriate events
• source
  • add member -> link to user profile
  • edit message -> link to message page
  • delete resource -> just resource name

RSS