Wiki source code of Activity Streams Component
Last modified by Vincent Massol on 2024/11/19 16:12
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | XWiki needs a component to record and store events happening inside the wiki. Examples of events are: create page, delete page, comment, attach etc. | ||
| 2 | |||
| 3 | = Recording Events = | ||
| 4 | |||
| 5 | First, we have to think about how will events be recorded. Here are two possible ways of doing this. | ||
| 6 | |||
| 7 | === Using notifications === | ||
| 8 | |||
| 9 | 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. | ||
| 10 | |||
| 11 | PROs | ||
| 12 | |||
| 13 | * cleaner code | ||
| 14 | * separation of concerns | ||
| 15 | |||
| 16 | CONs | ||
| 17 | |||
| 18 | * recorded event types restricted by notification capabilities | ||
| 19 | |||
| 20 | === Without using notifications === | ||
| 21 | |||
| 22 | 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. | ||
| 23 | |||
| 24 | PROs | ||
| 25 | |||
| 26 | * record any type of event (independent of the notification system) | ||
| 27 | |||
| 28 | CONs | ||
| 29 | |||
| 30 | * mixing concerns | ||
| 31 | * an event (like delete a page) could happened in many ways and we might end up having duplicated code or ignoring some behavior. | ||
| 32 | |||
| 33 | = Event Model = | ||
| 34 | |||
| 35 | An event is defined by the following questions: | ||
| 36 | |||
| 37 | * what? -> event type | ||
| 38 | * when? -> event date / time stamp | ||
| 39 | * who? -> event initiator | ||
| 40 | * where? -> event source and (where to look for) event effect | ||
| 41 | |||
| 42 | Therefore, we could model an event as follows: | ||
| 43 | |||
| 44 | **Event** | ||
| 45 | |||
| 46 | * type : int | ||
| 47 | * date : java.util.Date | ||
| 48 | * initiator : String ~/~/ wiki user name | ||
| 49 | * scope : String ~/~/ i.e. space name, virtual wiki name or something else | ||
| 50 | * source : String ~/~/ wiki page name | ||
| 51 | * data : String ~/~/ free text, requested by Jerome | ||
| 52 | |||
| 53 | Of course, we need a component to manage the events. | ||
| 54 | |||
| 55 | **EventManager** | ||
| 56 | |||
| 57 | * addEvent(type:int, scope:String, source:String, context:XWikiContext) : void | ||
| 58 | * addEvent(type:int, scope:String, source:String, data:String, context:XWikiContext) : void | ||
| 59 | * listEvents() : java.util.List | ||
| 60 | * listEvents(scope:String) : java.util.List | ||
| 61 | * queryEvents(sql: String) : java.util.List | ||
| 62 | |||
| 63 | Standard event types are: | ||
| 64 | |||
| 65 | * create / add | ||
| 66 | * edit | ||
| 67 | * move / rename | ||
| 68 | * delete | ||
| 69 | * comment | ||
| 70 | * attach | ||
| 71 | |||
| 72 | = Event Storage = | ||
| 73 | |||
| 74 | Once we have all the infos defining an event we must store it somehow. Here are two possibilities. | ||
| 75 | |||
| 76 | === Low level === | ||
| 77 | |||
| 78 | We can use a table, xwikievents, with the following schema: | ||
| 79 | |||
| 80 | * XWE_ID int(11) | ||
| 81 | * XWE_TYPE int(11) | ||
| 82 | * XWE_DATE datetime | ||
| 83 | * XWE_INITIATOR varchar(255) | ||
| 84 | * XWE_SCOPE varchar(255) | ||
| 85 | * XWE_SOURCE varchar(255) | ||
| 86 | * XWE_DATA varchar(255) | ||
| 87 | |||
| 88 | PROs | ||
| 89 | |||
| 90 | * simple custom query using queryEvents | ||
| 91 | |||
| 92 | CONs | ||
| 93 | |||
| 94 | * time to create the infrastructure | ||
| 95 | * not compatible with wiki replication | ||
| 96 | |||
| 97 | === High level === | ||
| 98 | |||
| 99 | 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. | ||
| 100 | |||
| 101 | PROs | ||
| 102 | |||
| 103 | * infrastructure already build | ||
| 104 | |||
| 105 | CONs | ||
| 106 | |||
| 107 | * 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. | ||
| 108 | * not 100% general | ||
| 109 | * complex custom queries | ||
| 110 | * generates updates in the wiki, potentially triggering wiki feeds additions, would need hidden space | ||
| 111 | * access to activity streams needs to be secured at the data level | ||
| 112 | |||
| 113 | = Event Visualization = | ||
| 114 | |||
| 115 | === Custom (project specific) === | ||
| 116 | |||
| 117 | * type -> choose the corresponding display mode | ||
| 118 | * date -> how long ago? | ||
| 119 | * user -> link to user profile | ||
| 120 | * scope -> used to select appropriate events | ||
| 121 | * source | ||
| 122 | ** add member -> link to user profile | ||
| 123 | ** edit message -> link to message page | ||
| 124 | ** delete resource -> just resource name | ||
| 125 | |||
| 126 | === RSS === |
