[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-even
26 Feb
2011
26 Feb
'11
8:58 a.m.
Hi Sergiu,
On Feb 26, 2011, at 12:00 AM, sdumitriu (SVN) wrote:
Author: sdumitriu
Date: 2011-02-26 00:00:44 +0100 (Sat, 26 Feb 2011)
New Revision: 34960
Added:
platform/core/trunk/xwiki-eventstream/
platform/core/trunk/xwiki-eventstream/pom.xml
platform/core/trunk/xwiki-eventstream/src/
platform/core/trunk/xwiki-eventstream/src/main/
platform/core/trunk/xwiki-eventstream/src/main/java/
platform/core/trunk/xwiki-eventstream/src/main/java/org/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/Event.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventStream.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEvent.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/resources/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/components.txt
platform/core/trunk/xwiki-eventstream/src/test/
platform/core/trunk/xwiki-eventstream/src/test/java/
platform/core/trunk/xwiki-eventstream/src/test/java/org/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventAndFactoryTest.java
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventGroupTest.java
Modified:
platform/core/trunk/pom.xml
Log:
XWIKI-6047: New EventStream component
That was new to me. Was this discussed (it's possible I missed a mail on the list)?
From the jira it seems this module is meant to be a replacement of the ActivityStream
plugin, right? If so what's the strategy to replace it (timing, backward compat,
etc)?
There seems to be a notion of Event similar to that of the Observation module.
Maybe Event is not the right term here seems the javadoc says "A recorded event that
happened at some point in the wiki". Maybe something like ArchiveEvent, PastEvent,
SavedEvent, etc And maybe these events should extend the Observation Event and add new
fields (date, etc)? Or maybe it's better to not extend but have a field that is the
original Observation Event object? Or maybe not and it's better to have no
relationship to the Observation module to be independent? In any case this should probably
be discussed/explained.
Maybe the Obervation module should be split in one more submodule called
xwiki-observation-store or xwiki-observation-history? It seems to me this could be about
historizing the events sent by the Observation managed.
To be honest, I haven't really thought about it enough (would need to load the code in
my IDE).
I find that this commit happens quite late in the release cycle (3 days before end of
milestone) and would have warranted some earlier discussion.
It's ok, I'm not asking to rollback, just saying that something this important
from an architecture point of view should rather be done earlier and discussed.
Thanks
-Vincent
26 Feb
26 Feb
9:36 a.m.
New subject: [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:
Hi Sergiu,
On Feb 26, 2011, at 12:00 AM, sdumitriu (SVN) 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?
Author: sdumitriu
Date: 2011-02-26 00:00:44 +0100 (Sat, 26 Feb 2011)
New Revision: 34960
Added:
platform/core/trunk/xwiki-eventstream/
platform/core/trunk/xwiki-eventstream/pom.xml
platform/core/trunk/xwiki-eventstream/src/
platform/core/trunk/xwiki-eventstream/src/main/
platform/core/trunk/xwiki-eventstream/src/main/java/
platform/core/trunk/xwiki-eventstream/src/main/java/org/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/Event.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventStream.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEvent.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/resources/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/components.txt
platform/core/trunk/xwiki-eventstream/src/test/
platform/core/trunk/xwiki-eventstream/src/test/java/
platform/core/trunk/xwiki-eventstream/src/test/java/org/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventAndFactoryTest.java
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventGroupTest.java
Modified:
platform/core/trunk/pom.xml
Log:
XWIKI-6047: New EventStream component
That was new to me. Was this discussed (it's possible I missed a mail on the list)?
> From the jira it seems this module is meant to be
a replacement of the ActivityStream plugin, right? If so what's the strategy to
replace it (timing, backward compat, etc)?
At some point yes, but we need the storage module before that. Any ETA
for storage?
There seems to be a notion of Event similar to that of
the Observation module.
Maybe Event is not the right term here seems the javadoc says "A recorded event that
happened at some point in the wiki". Maybe something like ArchiveEvent, PastEvent,
SavedEvent, etc And maybe these events should extend the Observation Event and add new
fields (date, etc)? Or maybe it's better to not extend but have a field that is the
original Observation Event object? Or maybe not and it's better to have no
relationship to the Observation module to be independent? In any case this should probably
be discussed/explained.
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.
Maybe the Obervation module should be split in one
more submodule called xwiki-observation-store or xwiki-observation-history? It seems to me
this could be about historizing the events sent by the Observation managed.
To be honest, I haven't really thought about it enough (would need to load the code
in my IDE).
I find that this commit happens quite late in the release cycle (3 days before end of
milestone) and would have warranted some earlier discussion.
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.
It's ok, I'm not asking to rollback, just
saying that something this important from an architecture point of view should rather be
done earlier and discussed.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
9:56 a.m.
New subject: [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 Feb 26, 2011, at 9:36 AM, Sergiu Dumitriu wrote:
On 02/26/2011 08:58 AM, Vincent Massol wrote:
hmm I'm not sure about this. I view it the other way around, ie all events must go
through notifications and some get saved (not all of course). Although this puts more
limitation it seems a stronger and simpler architecture to me:
* all events are sent as observation events
* this allows features such as remote events almost transparently
* this allows saving events transparently too
* allows adding lots of other feature in the future (logging of events for debug
purpose/real time view of what's happening in the system, etc)
IMO adding a xwiki-observation-history or -storage module makes the architecture more
cohesive and makes the observation module as a whole more important.
Having decoupling is good in general but has its limitations:
* necessity to write bridges between systems (serialization, marshalling)
* more ways for users to use them and thus needs more written best practices to give
directions
* makes it harder for a newcomer to use them
Right now I'm more inclined to say that the new "eventstream" should be
implemented as xwiki-observation-store/storage/history. But we need more input from other
committers too.
And this can be refactored later on if we flag the new module as experimental and unstable
in the release notes for 3.0 to ensure people won't use it (that won't ensure
anything but will cover ourselves a bit... hey didn't you read the release notes? ;)).
We'd need to refactor it in 3.1 though if we want to go in that direction.
Hi Sergiu,
On Feb 26, 2011, at 12:00 AM, sdumitriu (SVN) 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?
Author: sdumitriu
Date: 2011-02-26 00:00:44 +0100 (Sat, 26 Feb 2011)
New Revision: 34960
Added:
platform/core/trunk/xwiki-eventstream/
platform/core/trunk/xwiki-eventstream/pom.xml
platform/core/trunk/xwiki-eventstream/src/
platform/core/trunk/xwiki-eventstream/src/main/
platform/core/trunk/xwiki-eventstream/src/main/java/
platform/core/trunk/xwiki-eventstream/src/main/java/org/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/Event.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventStream.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEvent.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/resources/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/components.txt
platform/core/trunk/xwiki-eventstream/src/test/
platform/core/trunk/xwiki-eventstream/src/test/java/
platform/core/trunk/xwiki-eventstream/src/test/java/org/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventAndFactoryTest.java
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventGroupTest.java
Modified:
platform/core/trunk/pom.xml
Log:
XWIKI-6047: New EventStream component
That was new to me. Was this discussed (it's possible I missed a mail on the list)?
> From the jira it seems this module is meant
to be a replacement of the ActivityStream plugin, right? If so what's the strategy to
replace it (timing, backward compat, etc)?
At some point yes, but we need the storage module before that. Any ETA
for storage?
There seems to be a notion of Event similar to
that of the Observation module.
Maybe Event is not the right term here seems the javadoc says "A recorded event that
happened at some point in the wiki". Maybe something like ArchiveEvent, PastEvent,
SavedEvent, etc And maybe these events should extend the Observation Event and add new
fields (date, etc)? Or maybe it's better to not extend but have a field that is the
original Observation Event object? Or maybe not and it's better to have no
relationship to the Observation module to be independent? In any case this should probably
be discussed/explained.
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.
What is a "wider range of events"? What kind of events wouldn't be handled
by the Observation module?
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.
It's really the other way around. Events must be sent first and then listeners do what
they want: store them, etc.
This is the only performant and architecture-sound way I know to handle this. Otherwise it
means you're considering storage a special action, which it doesn't have to be.
It's an action like any other action that can happen on events.
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.
Sure about not being perfect (this is not the issue), and I've not asked to stop
anything.
Thanks
-Vincent
Maybe the Obervation module should be split in
one more submodule called xwiki-observation-store or xwiki-observation-history? It seems
to me this could be about historizing the events sent by the Observation managed.
To be honest, I haven't really thought about it enough (would need to load the code
in my IDE).
I find that this commit happens quite late in the release cycle (3 days before end of
milestone) and would have warranted some earlier discussion.
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. It's ok, I'm not asking to rollback, just
saying that something this important from an architecture point of view should rather be
done earlier and discussed.
--
Sergiu Dumitriu
9:38 a.m.
New subject: [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:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Sergiu,
On Feb 26, 2011, at 12:00 AM, sdumitriu (SVN) wrote:
It was said that user messages will be stored as activitystream events,
and it was implied that all new code should be written as components.
The natural conclusion to me was that there will be a bridge between AS
and components. So it wasn't explicitly discussed, but it was implied.
Author: sdumitriu
Date: 2011-02-26 00:00:44 +0100 (Sat, 26 Feb 2011)
New Revision: 34960
Added:
platform/core/trunk/xwiki-eventstream/
platform/core/trunk/xwiki-eventstream/pom.xml
platform/core/trunk/xwiki-eventstream/src/
platform/core/trunk/xwiki-eventstream/src/main/
platform/core/trunk/xwiki-eventstream/src/main/java/
platform/core/trunk/xwiki-eventstream/src/main/java/org/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/Event.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventStream.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEvent.java
platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEventFactory.java
platform/core/trunk/xwiki-eventstream/src/main/resources/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/
platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/components.txt
platform/core/trunk/xwiki-eventstream/src/test/
platform/core/trunk/xwiki-eventstream/src/test/java/
platform/core/trunk/xwiki-eventstream/src/test/java/org/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventAndFactoryTest.java
platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventGroupTest.java
Modified:
platform/core/trunk/pom.xml
Log:
XWIKI-6047: New EventStream component
That was new to me. Was this discussed (it's possible I missed a mail on the list)?
From the jira
it seems this module is meant to be a replacement of the ActivityStream plugin, right? If
so what's the strategy to replace it (timing, backward compat, etc)?
There seems to be a notion of Event similar to that of the Observation module.
Maybe Event is not the right term here seems the javadoc says "A recorded event that
happened at some point in the wiki". Maybe something like ArchiveEvent, PastEvent,
SavedEvent, etc And maybe these events should extend the Observation Event and add new
fields (date, etc)? Or maybe it's better to not extend but have a field that is the
original Observation Event object? Or maybe not and it's better to have no
relationship to the Observation module to be independent? In any case this should probably
be discussed/explained.
Maybe the Obervation module should be split in one more submodule called
xwiki-observation-store or xwiki-observation-history? It seems to me this could be about
historizing the events sent by the Observation managed.
To be honest, I haven't really thought about it enough (would need to load the code
in my IDE).
I find that this commit happens quite late in the release cycle (3 days before end of
milestone) and would have warranted some earlier discussion.
It's ok, I'm not asking to rollback, just saying that something this important
from an architecture point of view should rather be done earlier and discussed.
4951
days inactive
4951
days old
3 comments
2 participants
participants (2)
-
Sergiu Dumitriu -
Vincent Massol