#485: Topic-based pub/sub for IResourceChangeListener
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: nobody
Type: | Status: new
enhancement | Milestone:
Priority: major | Version:
Component: trac core | Keywords: gsoc IResourceChangeListener
Resolution: | performance
-------------------------+-------------------------------------------------
Changes (by olemis):
* owner: => nobody
* keywords: => gsoc IResourceChangeListener performance
* component: => trac core
Old description:
> Resource listeners often will watch events for a limited , well-known set
> of resource realms (e.g. `ticket` + `attachment` ) .
>
> The current dispatching strategy (i.e. `match_resource`) is mostly
> [http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
> content based] . It behaves in `O(r * l)` order of magnitude . This might
> lead to a lot of extra (unnecessary) overhead .
>
> A performance improvement could be to allow listeners to register to
> dedicated realm channels (i.e.
> [http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
> topic-based filtering]) , thus turning the dispatch algorithm into `O(l)`
> .
>
> PS: We shall not loose the current content-based filtering capabilities ,
> so in advance I advocated using a hybrid strategy .
New description:
Resource listeners often will watch events for a limited , well-known set
of resource realms (e.g. `ticket` + `attachment` ) .
The current dispatching strategy (i.e. `match_resource`) is mostly
[http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
content based] . It behaves in `O(r * l)` order of magnitude . This might
lead to a lot of extra (unnecessary) overhead .
A performance improvement could be to allow listeners to register to
dedicated realm channels (i.e.
[http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
topic-based filtering]) , thus turning the dispatch algorithm into `O(l)`
, at least when it is a ok to do so ;)
PS: We shall not loose the current content-based filtering capabilities ,
so in advance I advocated using a hybrid strategy .
--
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/485#comment:1>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
