Activity Streams Component
Description
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
CONs
- 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)
CONs
- 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
Therefore, we could model an event as follows:
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
Of course, we need a component to manage the events.
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
Standard event types are:
- 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)
PROs
- simple custom query using queryEvents
CONs
- 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
CONs
- 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