[Chandler-dev] Re: [Dev] collections and notifications

[Katie Capps Parlante]

Andi Vajda wrote:
> On Thu, 9 Mar 2006, Alec Flett wrote:
>> Also, I thought we agreed that all notifications coming out of the 
>> repository would be synchronous, and it was up to the UI (i.e. me, or 
>> someone else on the Apps team) to queue them up if we needed 
>> asynchronous notifications. Can we make this one synchronous too, and 
>> leave the responsibility for queuing up notifications for async 
>> delivery to the frontend? (i.e. keep asynchronicity "above the line")
> 
> Yes, we agreed to this but as I implemented it it became clear that it 
> was going to be way too expensive for a perf standpoint to do 
> synchronously.
> The collection item notifications are quite pricey because they're 
> propagated up the entire collection item tree. Doing it asynchronously 
> ensures that 20 changes to the same item are actually just one such 
> notification.
> So, I went back and forth over this and ended up keeping what Ted and 
> John had done for 0.6 but move it below the line.

I wanted to follow up on this to make sure all is well. If I understand 
correctly...

- "Item notifications" have been implemented (watchItem), and are 
synchronous, and this will meet the detail view requirements for item 
notifications

- Most notifications are synchronous
    - attribute monitors (which are probably mostly used internally in 
the repository, to maintain indexes and whatnot)
    - watchItem
    - watchKind
    - watchCollection

- "watchQueue" is asynchronous

A few questions:
- When does one use "watchQueue" vs "watchCollection"? (Andi has 
documented this from a bottom up perspective, but how do we explain this 
  clearly to people writing code at higher layers?)

- We had talked about deliverNotifications/mapChanges as having become 
something of a "Frankenstein" in 0.6. At the collections meeting, we 
theorized that onIdle could just call view.refresh() and that 
deliverNotifications() could go away, given that all of the "below the 
line" notifications would be synchronous. Given that watchQueue remains 
asynchronous for performance reasons, where does that leave us? Are we 
happy that the current implementation of deliverNotifications() is 
reasonable? Are we happy with the options/consequences at the app level?

- Does Bryan have everything he needs for detail view work (wrt 
notifications)? If not, what remains?

Cheers,
Katie