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.
What I like in the use-cases is the notion of grouping (this tastes like a transaction id
of some sort): 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).
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.
Paul
On 18 juil. 2014, at 16:32, Eduard Moraru <enygma2002(a)gmail.com> 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/AcitvityStreamRefactoring62…
[3]
http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs