Let alternative impls of EventTrackingService handle some Events
GENERAL
TESTING
GENERAL
TESTING
Description
We are working on a new service/tool for sakai 2.9 to replace current synoptic tools with a much more performant mashup of entities relevant to the user. This would be a dashboard containing two lists of items – "calendar" items with due dates or other time-based tracking in the immediate future, and "news" items about creation or modification of relevant entities in the very recent past. To make this perform well, we propose a new service that converts events into items targeted for specific users at the time relevant events are posted to EventTrackingService. Our design calls for capturing information from the event stream as it is posted so the creation of dashboard items before events, rather than after. That way, in a cluster, the creation of dashboard items can be done on one server and made available to other servers instead of having each server process each event in this way.
Those details are still being worked out and will be handled under a separate ticket. But in the meantime, we would like to do exploratory work on creation of a new implementation of EventTrackingService that would delegate most method calls to the existing impl. But it would also allow other impls of ETS to participate in handling events instead of or in addition to the existing impl. This exploratory work would be done in a branch and, depending on the results, we would produce a patch and propose merging it to trunk in time for 2.9.
Activity
Show:
Jim Eng March 31, 2011 at 6:59 PM
There's a much simpler way to accomplish the same thing with less impact and less risk.
We are working on a new service/tool for sakai 2.9 to replace current synoptic tools with a much more performant mashup of entities relevant to the user. This would be a dashboard containing two lists of items – "calendar" items with due dates or other time-based tracking in the immediate future, and "news" items about creation or modification of relevant entities in the very recent past. To make this perform well, we propose a new service that converts events into items targeted for specific users at the time relevant events are posted to EventTrackingService. Our design calls for capturing information from the event stream as it is posted so the creation of dashboard items before events, rather than after. That way, in a cluster, the creation of dashboard items can be done on one server and made available to other servers instead of having each server process each event in this way.
Those details are still being worked out and will be handled under a separate ticket. But in the meantime, we would like to do exploratory work on creation of a new implementation of EventTrackingService that would delegate most method calls to the existing impl. But it would also allow other impls of ETS to participate in handling events instead of or in addition to the existing impl. This exploratory work would be done in a branch and, depending on the results, we would produce a patch and propose merging it to trunk in time for 2.9.