On 02/26/2011 08:58 AM, Vincent Massol wrote:
> 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)?

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?

>> 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/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to