Re: [xwiki-devs] EventStream module (was Re: [xwiki-notifications] r34960 - in platform/core/trunk: . xwiki-eventstream xwiki-eventstream/src xwiki-eventstream/src/main xwiki-eventstream/src/main/java xwiki-eventstream/src/main/java/org xwiki-eventstream/src/main/java/org/xwiki xwiki-eventstream/src/main/java/org/xwiki/eventstream xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal xwiki-eventstream/src/main/resources xwiki-eventstream/src/main/resources/META-INF xwiki-eventstream/src/test xwiki-

On 02/26/2011 08:58 AM, Vincent Massol wrote: I needed a way to store user messages without depending on the activity stream plugin. This is just a wrapper on top of the activity stream plugin. Now that you mentioned it, I'm not sure the "Event" term is 100% compatible with "user message", WDYT? At some point yes, but we need the storage module before that. Any ETA for storage? Events can come from other sources than observation events, so it's not equivalent. Most activity events will be created at the same time as an observation event is fired. Personally I don't like to relate them. They are both effects of some activity in the wiki, but one can occur without the other and vice-versa. - not all observation events are logged (none of the rendering events are that interesting, storing them will just be a waste of database storage; same with ActionExecutionEvents, that would be duplicating analytics and statistics) - not all activity events will be created through notifications. I see the relationship ObservationEvent->ActivityStreamEvent as a mere technological evolution accident, and not something done on complete purpose. Initially this was a way to decouple the ActivityStream plugin from the core, since events were already being sent (the old notification events), and there was no good reason to hardcore AS in the core. Then Notifications were replaced by ObservationEvents, then more events and more activities were added to support the new and improved Activity widget, and now I'm introducing clean activity events to be used for a wider range of events. The real relationship between the two types of events should actually be the other way around. Something happens in the wiki, so we: 1/ store this for historical reasons (view the activity in the dashboard, security audits, statistics, etc.) 2/ let possible interested parties know about this, so they can clear their caches, or compute some data, or send mails, or whatever it is they want to do when something relevant happens. And since geeks start counting at 0 and we have such a cool platform: 0/ check that the activity is valid by sending a cancelable observation event, and if someone doesn't like this, abort the whole process and throw an error right in the user's face. It happens when it's ready, I couldn't have committed it before it was done. There were discussions when the activity stream plugin was designed, Marius did a good job from the start; I found it good enough to use in the future, so I simply pruned the nasty part (param1..param5), I updated some methods to current practices (replaced strings with proper References), and I ironed out some method names. Sprinkled a bit of Javadoc on top, and it's out without another couple of weeks of discussions. It can be enhanced on the run, no need to halt everything until it's perfect, because it never will be. -- Sergiu Dumitriu http://purl.org/net/sergiu/