[Dev] Notification Manager using Item Queries

[Brian Kirsch]

Hi Ted,
Where I see the addition overhead of commits in is the true event cases 
such as in your Shtoom example from IRC on Friday when a phone call is 
coming. In the Item Query model we would have a ShtoomEvent item with a 
inbound flag attribute which would get set and commited. The listener 
would be notified and do a refresh. Comparing this to
a Notification Manager, the manager would get the event posted to it 
directly and pass the event on the the listeners bypassing the 
repository entirely.

I am kinda torn right now cause I see a lot of advantages to having 
queries be the means of notification. But I do not
want to adversely impact performance given Chandler's current 
performance deficiencies.




Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor 
San Francisco, CA 94105 
(415) 946-3056 

On Dec 6, 2004, at 11:40 AM, Ted Leung wrote:

> Just so that we're clear here, I'm not invested in doing notification 
> exclusively via queries, so I don't mind if we decide to do a 
> "regular" notification manager.  Having said that...
>
> On Dec 6, 2004, at 11:12 AM, Brian Kirsch wrote:
>
>> Technically I think it is possible to use item queries to deliver 
>> notifications across views / threads. My concern is with repository 
>> performance. The additional number of refreshes and commits required 
>> to propagate notifications across views is gonna add a lot of CPU 
>> cycles to the Repository Layer.
>
> What it comes down to is this.  If we have to actually communicate 
> changes in items across views, then we will have to commit/refresh in 
> order for those changes to be visible. This is a direct consequence of 
> our transaction model.  At that point, adding a notification on top of 
> that isn't going to be that much overhead, compared to the overhead of 
> the commit.  The only way that I can see around this would be to pass 
> all the values needed by the notified repository view in the 
> notification itself.
>
> I am also concerned about performance, but I also don't think that 
> this is an all or nothing proposal.  If we do a regular style 
> notification manager, we can always (gradually) switch over to a query 
> based system if that turns out to be efficient enough.
>
> Ted
>