[Dev] Notification Manager using Item Queries

Katie Capps Parlante capps at osafoundation.org
Mon Dec 6 21:37:52 PST 2004

Hi Brian,

The Shtoom example may indeed end up working out better with a 
notification manager, but I don't think this case is typical of what we 
need in .5 or even for Kibble features.

Here's my understanding of the use cases that we are immediately 
concerned with (which is admittedly a bit ui centric):

1) A background thread (meaning, not a ui thread) makes changes to 
content items in the repository. The ui thread needs to notice these 
changes. Its fine if the ui thread gets notified only when the 
background thread commits the changes to the repository. These types of 
changes need to be noticed: an  attribute value on an item changes, an 
item leaves a collection, an item enters a collection. The plan for this 
type of use case is to use query/collection notifications, which means 
the ui thread will only get the notifications for items that are in 
queries/collections. My understanding is that this restriction is 
reasonable, content items will be in collections. Note, when the ui 
thread gets this notification, the ui code can decide when/how/if it 
wants to do a repository refresh to pick up the changes from the 
background thread.

2) The ui thread makes changes to content items or cpia items, and the 
same ui thread needs to "notice" the changes. For example: the detail ui 
view changes an item's attribute value, and the summary ui view needs to 
do a repaint with the new value. Notice that in this case we are talking 
about the same thread and the same repository view, so no "repository 
refresh" is needed -- we just need to let the summary ui view know that 
it needs to do a repaint. We're looking at the option of using 
query/collection notifications in this case as well, it would be great 
if this all worked quickly/smoothly without a commit. If that approach 
proves problematic because of performance or for some other reason, we 
may need to explore another way of getting this case right. Also note 
that now that we are talking about cpia items, right now they are all in 
collections. (Ted, let me know if I have the details wrong here about 
how we think this might work.)

If we refactor the ui thread to use multiple repository views then we'll 
need to commit/refresh to share data between the views. So far, we don't 
have a clear proposal/architecture where this would make sense, but 
that's perhaps a separate conversation. If we want to go this route, we 
ought to be clear about how this would work before worrying about 
notifications between multiple ui repository views.

Looking at performance, we really care that the ui thread is super 
responsive. We can probably tolerate a slight delay for the background 
thread --> ui thread communication -- I don't think this has been the 
source of application sluggishness thus far.


Brian Kirsch wrote:

> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

More information about the Dev mailing list