12 Jul
2011
12 Jul
'11
6:09 p.m.
Hi devs,
I would like to introduced a standardized (at observation API level)
way to indicate that en event represent the beginning or the end of
something. The idea is them to use it in things like activity stream
to group events/whatever or in my case maintain a stack of states in
the Execution context about the current action updated by listening to
events.
My immediate use case is to filter some modification in automatic
watch feature (imported xar, crated wikis, etc.) but I feel that we
need that information for a larger audience.
In details my proposal is to introduce BeginEvent and EndEvent
interface (feel free to suggest better names if you have some in
mind). Then pushing the BeginEvent instance in the context in a stack
of current events poped when receiving a EndEvent.
Note that I don't not plan to put an id in Begin/EndEvent since it
should not be needed if they are properly generated (some job can't
finish if all it's sub jobs are not finished).
WDYT ?
--
Thomas Mortagne
13 Jul
13 Jul
8:53 a.m.
Hi Thomas,
On Jul 12, 2011, at 6:09 PM, Thomas Mortagne wrote:
Hi devs,
I would like to introduced a standardized (at observation API level)
way to indicate that en event represent the beginning or the end of
something. The idea is them to use it in things like activity stream
to group events/whatever
Yes, I'd like that too (we talked about it offline actually ;)) so that we can have
higher level events wrapping smaller ones. For example a Rename event wrapping the Copy +
Delete events and showing up as a Rename event in the Activity Stream (with the
possibility to expand it to show enclosed events). The same could be done for a XAR
import: a high level XAR Import event wrapping all Doc creation/update events so that it
doesn't "pollute" the Activity Stream. We can imagine lots of
Application-level events like this.
or in my case maintain a stack of states in
the Execution context about the current action updated by listening to
events.
My immediate use case is to filter some modification in automatic
watch feature (imported xar, crated wikis, etc.) but I feel that we
need that information for a larger audience.
Yep definitely.
Note that this change will mean the following changes too in the future:
* Modify the Activity Stream to handle beginning/end events and nested events
In details my proposal is to introduce BeginEvent and
EndEvent
interface (feel free to suggest better names if you have some in
mind). Then pushing the BeginEvent instance in the context in a stack
of current events poped when receiving a EndEvent.
context = Execution Context
One thing to be careful of is that we'll need to use try/finally block wherever we
send these events to be sure the EndEvent is always sent as otherwise it'll lead to
"stack corruption".
Note that I don't not plan to put an id in
Begin/EndEvent since it
should not be needed if they are properly generated (some job can't
finish if all it's sub jobs are not finished).
WDYT ?
+1
Thanks
-Vincent
9:36 a.m.
On Wed, Jul 13, 2011 at 8:53 AM, Vincent Massol <vincent(a)massol.net> wrote:
Yea a tend to say "context" for ExecutionContext and "XWiki context"
for the old one ;)
--
Thomas Mortagne
Hi Thomas,
On Jul 12, 2011, at 6:09 PM, Thomas Mortagne wrote:
Yep that's the long term plan but I will let someone else take care of
that (I hope) ;)
Hi devs,
I would like to introduced a standardized (at observation API level)
way to indicate that en event represent the beginning or the end of
something. The idea is them to use it in things like activity stream
to group events/whatever
Yes, I'd like that too (we talked about it offline actually ;)) so that we can have
higher level events wrapping smaller ones. For example a Rename event wrapping the Copy +
Delete events and showing up as a Rename event in the Activity Stream (with the
possibility to expand it to show enclosed events). The same could be done for a XAR
import: a high level XAR Import event wrapping all Doc creation/update events so that it
doesn't "pollute" the Activity Stream. We can imagine lots of
Application-level events like this.
or in my case maintain a stack of states in
the Execution context about the current action updated by listening to
events.
My immediate use case is to filter some modification in automatic
watch feature (imported xar, crated wikis, etc.) but I feel that we
need that information for a larger audience.
Yep definitely.
Note that this change will mean the following changes too in the future:
* Modify the Activity Stream to handle beginning/end events and nested events In details my proposal is to introduce BeginEvent
and EndEvent
interface (feel free to suggest better names if you have some in
mind). Then pushing the BeginEvent instance in the context in a stack
of current events poped when receiving a EndEvent.
context = Execution Context
One thing to be careful of is that we'll need to use try/finally block wherever we
send these events to be sure the EndEvent is always sent as otherwise it'll lead to
"stack corruption".
Yep without id you need to be careful with how you deal with EndEvent.
Note that I don't not plan to put an id in
Begin/EndEvent since it
should not be needed if they are properly generated (some job can't
finish if all it's sub jobs are not finished).
WDYT ?
+1
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:13 a.m.
Sounds good +1
Jerome
On Tue, Jul 12, 2011 at 6:09 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
I would like to introduced a standardized (at observation API level)
way to indicate that en event represent the beginning or the end of
something. The idea is them to use it in things like activity stream
to group events/whatever or in my case maintain a stack of states in
the Execution context about the current action updated by listening to
events.
My immediate use case is to filter some modification in automatic
watch feature (imported xar, crated wikis, etc.) but I feel that we
need that information for a larger audience.
In details my proposal is to introduce BeginEvent and EndEvent
interface (feel free to suggest better names if you have some in
mind). Then pushing the BeginEvent instance in the context in a stack
of current events poped when receiving a EndEvent.
Note that I don't not plan to put an id in Begin/EndEvent since it
should not be needed if they are properly generated (some job can't
finish if all it's sub jobs are not finished).
WDYT ?
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Jul
20 Jul
4:46 p.m.
Hello,
On Tue, Jul 12, 2011 at 7:09 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
I would like to introduced a standardized (at observation API level)
way to indicate that en event represent the beginning or the end of
something. The idea is them to use it in things like activity stream
to group events/whatever or in my case maintain a stack of states in
the Execution context about the current action updated by listening to
events.
My immediate use case is to filter some modification in automatic
watch feature (imported xar, crated wikis, etc.) but I feel that we
need that information for a larger audience.
In details my proposal is to introduce BeginEvent and EndEvent
interface (feel free to suggest better names if you have some in
mind). Then pushing the BeginEvent instance in the context in a stack
of current events poped when receiving a EndEvent.
Note that I don't not plan to put an id in Begin/EndEvent since it
should not be needed if they are properly generated (some job can't
finish if all it's sub jobs are not finished).
WDYT ?
Definitely +1.
Raluca.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4839
days inactive
4847
days old
4 comments
4 participants
participants (4)
-
Jerome Velociter -
Raluca Stavro -
Thomas Mortagne -
Vincent Massol