Hello fellow developers,
Why exactly are you subclassing ActivityStream to achieve that?
Mmm, I am not sure of the original reason. That was Ludovic and Marius in 2008. At that point, it makes sense to subclass the ActivityStreamPlugin and register the… CurrikiActivityStream.
Why not use XWiki`s Observation Modules [1]? That`s what AS uses to immediately catch events and store them.
It is very likely that the CurrikiActivityStream has been a shallow copy of the ActivityStream of XWiki with overrides where needed, and grew at the same times as the activityStream grew.
You can do the same for immediate notifications.
That's what we are doing right now. The listener needs some application-special logic: e.g. so that events can say "sent to roles x/y/z of this group" or "sent this message".
For daily digests, just use a daily scheduler job and get the recorded events from AS for the day that just passed.
That's done and deployed on gpsnetwork.org.
Also, how exactly are you using the events to offer "notifications"? Can you offer more details?
That's in https://github.com/xwiki-contrib/currikiorg/blob/master/plugins/currikiactiv... and following. The idea is that the application-specific processing is something we want to leverage but still use Groovy pages to send the mail the appropriate group members. So we call back groovy from java, in a background thread triggered by the observation listener call.
On a related topic, would you find it interesting to have the output of the activity macro (with your filters/parameters applied to it) as JSON so that you would use it in your application? Would a REST (xml/json output) resource for reading events be better instead of a macro in a wiki page?
Probably one of them. But we've had different macros since ages… there's no urgency to use a new API. Also, service-based displays of data are more fragile because they break if javascript breaks. paul