Hi Paul, On Sat, Jul 19, 2014 at 1:04 AM, Paul Libbrecht <[email protected]> wrote:
> Hello Eduard, > > It's funny that this happens right now, while we are fiddling in the > ActivityStream (of XWiki 3.5.1, as subclassed by curriki). > We are doing so to offer notifications for gpsnetwork.org: daily digests > and immediate. > > So the first request is to enable a hook for immediate notification (a > groovy page?) and digest notifications, I find. > Why exactly are you subclassing ActivityStream to achieve that? Why not use XWiki`s Observation Modules [1]? That`s what AS uses to immediately catch events and store them. You can do the same for immediate notifications. For daily digests, just use a daily scheduler job and get the recorded events from AS for the day that just passed. Also, how exactly are you using the events to offer "notifications"? Can you offer more details? 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? ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module+Local > > What I like in the use-cases is the notion of grouping (this tastes like a > transaction id of some sort): This is already supported by the current AS implementation, but in a crude way. Basically, all events have a requestID [2] (or group [3][4] if you`re using eventstream's API). The current implementation of this is to assign an ID to the current request and pass that ID to all the events generated in the same request, by using/sharing the same XWiki context. It is in the right direction, but if you do a lot of stuff (programatically) in the same request, it is too noisy and becomes not relevant. It is useful for UI actions though, as they tend to be more focused than programatic ones. There still remains the problem of prioritising the events within the same group/request, which is not solved yet. ---------- [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/java/com/xpn/xwiki/plugin/activitystream/api/ActivityEvent.java#L48 [3] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/Event.java#L119 [4] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java > I am sure we can make use of this in various places, including the way to > track the series of save operations that happen when you create a document > or resource (currently, Curriki has a minimum version numbers and, not > surprisingly, one one of them was wrong). > Can you offer more details on this? > > The big deal of performance and extensibility sounds quite hard to me. > They are opposed to each other. > We know that the ActivityStream can be hogged and we would avoid relying > on it if we create some intensive event stream (e.g. in some form of > analytics); nonetheless, the performance sounds reasonable thus far. > Extensibility cannot happen thus far. We have… param1, param2, …, param5. > And that is almost enough (we started to add one of them to be a json > record to get more space!). The problem with extensibility is the storage > form: If you add an event type, you add a hibernate mapping. > > Curriki has wrapped events for this: they are created based on param1, …, > param5 and document names, when the stream is displayed. > > When pondering real hard core analytics, we have been considering a few > alternatives, e.g. CouchDB or MongoDB. But this has never made its way. I > am convinced Solr would do the trick too. > Somehow, there must be storage forms that take advantage of the very > peculiar nature of the event streams: > - only inserts, no updates > - reads that can be application defined, and probably can assert that an > amount of events is not useful anymore. > > As for the all the research about the macro, we stay way from that, since > Curriki has its own set of UIs. > Ok, so we are talking about a storage level extensibility here. More exactly, how to support various (new) event type's parameters [5]. Please see my comment on that issue [5] about using a list of parameters (instead of the problematic map and of the current param1..param5 implementataion). Would that help towards a decently performant extensibility improvement? Going for a NoSQL solution just for this problem might be a bit of overengineering... Thanks, Eduard ---------- [5] http://jira.xwiki.org/browse/XWIKI-7554 > > Paul > > > > On 18 juil. 2014, at 16:32, Eduard Moraru <[email protected]> wrote: > > > Hi devs, > > > > As part of the investigation on the Activity Stream Refactoring for the > 6.2 > > roadmap, I have written a couple of documents [1] on some of the problems > > (specifically performance [2]) of the current implementation and also > tried > > to list various use cases [3] that a better AS implementation should > > support. > > > > I would like to ask you to: > > - help out in listing possible use cases [3] that I have missed or you`d > > like AS to support, > > - offer your opinion on my current findings [1] and/or > > - share your thoughts on where should we go with the new implementation > of > > AS. > > > > Thanks, > > Eduard > > > > ---------- > > [1] > > > http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62 > > [2] > > > http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62Performance > > [3] > > > http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62UseCases > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
