[xwiki-devs] [Proposal] Introduce a BeginIgnoreEvent/EndIgnoreEvent classes and clarify Begin/EndFoldEvent usage
Hi devs, I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things. Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events. Current situation: * We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line). Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent. WDYT? Thanks -Vincent
The problem is that "ignore" seems to be more obvious for you that it is in reality. What you call "completely ignore" is actually ignore it in things like auto watchlist and activity stream but you certainly don't want solr, clustering or right system to ignore those. On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net <vincent@massol.net> wrote:
Hi devs,
I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things.
Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events.
Current situation:
* We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line).
Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 4 Feb 2016 at 15:27:18, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
The problem is that "ignore" seems to be more obvious for you that it is in reality. What you call "completely ignore" is actually ignore it in things like auto watchlist and activity stream but you certainly don't want solr, clustering or right system to ignore those.
That would work. If some listener doesn’t want to ignore some events (because it *has* to support them for things to work fine) then it would not ignore them. But the semantics would remain that they should be ignored *whenever* possible. Note that there are probably not that many use cases where we really want to ignore some events (since after all in a wiki everything should be tracked) but I think those use cases exist. It could be argued that even in the case of Spam cleaning we would want an entry in the AS that would say “Spam cleaning executed”. However when the AS implements the ability to see nested events, they should not be shown in this case (they should be ignored). Thanks -Vincent
On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net wrote:
Hi devs,
I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things.
Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events.
Current situation:
* We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line).
Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
WDYT?
Thanks -Vincent
Seems to me what you want is a way to indicate that something is technical and then very end user oriented things like activity stream should not show them. Not sure what is the best naming for it but at least I think "Hidden" event would be more consistent with hidden documents which is used for more or less the same thing ("technical stuff probably most people don't care about by default"). On Thu, Feb 4, 2016 at 3:36 PM, vincent@massol.net <vincent@massol.net> wrote:
On 4 Feb 2016 at 15:27:18, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
The problem is that "ignore" seems to be more obvious for you that it is in reality. What you call "completely ignore" is actually ignore it in things like auto watchlist and activity stream but you certainly don't want solr, clustering or right system to ignore those.
That would work. If some listener doesn’t want to ignore some events (because it *has* to support them for things to work fine) then it would not ignore them. But the semantics would remain that they should be ignored *whenever* possible.
Note that there are probably not that many use cases where we really want to ignore some events (since after all in a wiki everything should be tracked) but I think those use cases exist. It could be argued that even in the case of Spam cleaning we would want an entry in the AS that would say “Spam cleaning executed”. However when the AS implements the ability to see nested events, they should not be shown in this case (they should be ignored).
Thanks -Vincent
On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net wrote:
Hi devs,
I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things.
Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events.
Current situation:
* We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line).
Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
WDYT?
Thanks -Vincent
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 4 Feb 2016 at 15:43:54, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
Seems to me what you want is a way to indicate that something is technical and then very end user oriented things like activity stream should not show them. Not sure what is the best naming for it but at least I think "Hidden" event would be more consistent with hidden documents which is used for more or less the same thing ("technical stuff probably most people don't care about by default”).
I’d be fine with using BeginHiddenEvent/EndHiddenEvent instead of BeginIgnoredEvent/EndIgnoredEvent Thanks -Vincent
On Thu, Feb 4, 2016 at 3:36 PM, vincent@massol.net wrote:
On 4 Feb 2016 at 15:27:18, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
The problem is that "ignore" seems to be more obvious for you that it is in reality. What you call "completely ignore" is actually ignore it in things like auto watchlist and activity stream but you certainly don't want solr, clustering or right system to ignore those.
That would work. If some listener doesn’t want to ignore some events (because it *has* to support them for things to work fine) then it would not ignore them. But the semantics would remain that they should be ignored *whenever* possible.
Note that there are probably not that many use cases where we really want to ignore some events (since after all in a wiki everything should be tracked) but I think those use cases exist. It could be argued that even in the case of Spam cleaning we would want an entry in the AS that would say “Spam cleaning executed”. However when the AS implements the ability to see nested events, they should not be shown in this case (they should be ignored).
Thanks -Vincent
On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net wrote:
Hi devs,
I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things.
Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events.
Current situation:
* We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line).
Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
WDYT?
Thanks -Vincent
I remember that one reason to create BeginFoldEvent/EndFoldEvent was that
it depends on the context either or not it should be ignored. Said
differently, an event is not "ignorable" by nature.
In your case, maybe you should send a more specific event, like
"BeginSpamCleaning".
My 2 cents,
2016-02-04 15:36 GMT+01:00 vincent@massol.net <vincent@massol.net>:
>
> On 4 Feb 2016 at 15:27:18, Thomas Mortagne (thomas.mortagne@xwiki.com
> (mailto:thomas.mortagne@xwiki.com)) wrote:
>
> > The problem is that "ignore" seems to be more obvious for you that it
> > is in reality. What you call "completely ignore" is actually ignore it
> > in things like auto watchlist and activity stream but you certainly
> > don't want solr, clustering or right system to ignore those.
>
> That would work. If some listener doesn’t want to ignore some events
> (because it *has* to support them for things to work fine) then it would
> not ignore them. But the semantics would remain that they should be ignored
> *whenever* possible.
>
> Note that there are probably not that many use cases where we really want
> to ignore some events (since after all in a wiki everything should be
> tracked) but I think those use cases exist. It could be argued that even in
> the case of Spam cleaning we would want an entry in the AS that would say
> “Spam cleaning executed”. However when the AS implements the ability to see
> nested events, they should not be shown in this case (they should be
> ignored).
>
> Thanks
> -Vincent
>
>
> > On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net wrote:
> > > Hi devs,
> > >
> > > I’m not sure if we are all on the same page on the topic of ignoring
> and folding events so I’m making this proposal to try to clarify things.
> > >
> > > Needs:
> > > * Use case 1: Ability to ignore events. For example when cleaning
> spam, since we’re removing pages with spam in the title we may not want to
> have those pages appear in the Activity Stream, so the cleaning tool should
> be able to ignore events.
> > > * Use case 2: Grouping of Events. For example when we import a XAR we
> don’t want that each page in the XAR appear as a change in the Activity
> Stream since that would flood the stream. Instead we want to have a single
> entry that says “XAR xxx has been imported” (and ideally have the ability
> to click on a details link to unfold the full list of nested events.
> > >
> > > Current situation:
> > >
> > > * We currently have a Begin/EndFoldEvent which correspond to use case
> 2. The javadoc for Being says: "Implemented by event indicating a task
> which generates other events during its process is starting. This generated
> events could be seen as children of this task, that you can fold. This
> interface should only be used when there is a corresponding {@link
> EndFoldEvent}.”.
> > > * We don’t have any specific Event to say that we want to ignore all
> the events that come after it.
> > > * A lot of Event Listeners are currently excluding Begin/EndFoldEvent.
> > > ** For example the AS completely ignores any BeginFoldEvent sent to it
> (which is not correct, it should at least log one line).
> > >
> > > Proposal:
> > > * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means
> that nested events are sent between the Begin/End.
> > > * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use
> case 1 (i.e. when some code needs to completely have the following events
> ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Delhumeau (guillaume.delhumeau@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 4 Feb 2016 at 15:45:13, Guillaume Delhumeau (guillaume.delhumeau@xwiki.com(mailto:guillaume.delhumeau@xwiki.com)) wrote:
> I remember that one reason to create BeginFoldEvent/EndFoldEvent was that
> it depends on the context either or not it should be ignored. Said
> differently, an event is not "ignorable" by nature.
>
> In your case, maybe you should send a more specific event, like
> "BeginSpamCleaning”.
You cannot send a BeginFoldEvent Guillaume, It’s an interface! :)
I do send a Begin/EndSpamCleaning event but I don’t see the point in the discussion. The discussion is not about the sender but about how the receiving end need to be react to event (ie semantic meaning of events).
You cannot suggest that listener should know about ALL possible Events in the system and in extensions (and future extensions).
Thanks
-Vincent
> My 2 cents,
>
> 2016-02-04 15:36 GMT+01:00 vincent@massol.net :
>
> >
> > On 4 Feb 2016 at 15:27:18, Thomas Mortagne (thomas.mortagne@xwiki.com
> > (mailto:thomas.mortagne@xwiki.com)) wrote:
> >
> > > The problem is that "ignore" seems to be more obvious for you that it
> > > is in reality. What you call "completely ignore" is actually ignore it
> > > in things like auto watchlist and activity stream but you certainly
> > > don't want solr, clustering or right system to ignore those.
> >
> > That would work. If some listener doesn’t want to ignore some events
> > (because it *has* to support them for things to work fine) then it would
> > not ignore them. But the semantics would remain that they should be ignored
> > *whenever* possible.
> >
> > Note that there are probably not that many use cases where we really want
> > to ignore some events (since after all in a wiki everything should be
> > tracked) but I think those use cases exist. It could be argued that even in
> > the case of Spam cleaning we would want an entry in the AS that would say
> > “Spam cleaning executed”. However when the AS implements the ability to see
> > nested events, they should not be shown in this case (they should be
> > ignored).
> >
> > Thanks
> > -Vincent
> >
> >
> > > On Thu, Feb 4, 2016 at 3:18 PM, vincent@massol.net wrote:
> > > > Hi devs,
> > > >
> > > > I’m not sure if we are all on the same page on the topic of ignoring
> > and folding events so I’m making this proposal to try to clarify things.
> > > >
> > > > Needs:
> > > > * Use case 1: Ability to ignore events. For example when cleaning
> > spam, since we’re removing pages with spam in the title we may not want to
> > have those pages appear in the Activity Stream, so the cleaning tool should
> > be able to ignore events.
> > > > * Use case 2: Grouping of Events. For example when we import a XAR we
> > don’t want that each page in the XAR appear as a change in the Activity
> > Stream since that would flood the stream. Instead we want to have a single
> > entry that says “XAR xxx has been imported” (and ideally have the ability
> > to click on a details link to unfold the full list of nested events.
> > > >
> > > > Current situation:
> > > >
> > > > * We currently have a Begin/EndFoldEvent which correspond to use case
> > 2. The javadoc for Being says: "Implemented by event indicating a task
> > which generates other events during its process is starting. This generated
> > events could be seen as children of this task, that you can fold. This
> > interface should only be used when there is a corresponding {@link
> > EndFoldEvent}.”.
> > > > * We don’t have any specific Event to say that we want to ignore all
> > the events that come after it.
> > > > * A lot of Event Listeners are currently excluding Begin/EndFoldEvent.
> > > > ** For example the AS completely ignores any BeginFoldEvent sent to it
> > (which is not correct, it should at least log one line).
> > > >
> > > > Proposal:
> > > > * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means
> > that nested events are sent between the Begin/End.
> > > > * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use
> > case 1 (i.e. when some code needs to completely have the following events
> > ignored). Those classes would implement BeginFoldEvent and EndFoldEvent.
> > > >
> > > > WDYT?
> > > >
> > > > Thanks
> > > > -Vincent
> > _______________________________________________
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Guillaume Delhumeau (guillaume.delhumeau@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Guillaume Delhumeau -
Thomas Mortagne -
vincent＠massol.net