On Thu, 9 Mar 2006, Alec Flett wrote:
The "collection item notifications" seem to have a distinctly different API
than the other notifications. instead of 'subscriber.watchXXX(item, ...,
methodName)' it is in the form
'collection.notificationQueueSubscribe(subscriber)'
Is there a reason it has this different API? The other methods are actual
methods on the subscriber, rather than the item being subscribed to. Second,
the other systems allow you to specify a method name, which seems quite
valuable.. It seems like it would be nice to be consistent with the APIs
across all the notification systems.
No particular reason other than history. I've been wondering about that
myself. Maybe I'll add a watchQueue(collectionItem, methodName) API....
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.
Random other things:
1) should watchKind also take a 'recursive' parameter to decide if it should
also watch sub-kinds of the given kind? Seems like that would be consistent
with other APIs that refer to kinds/subkinds
Currently it is recursive. Such an argument could be added...
2) Is there a reason that kind watchers don't fire during view refresh? I
guess I look at changes that result from view refreshes as being identical to
any other changes within the current view...
No good reason other than it's not implemented that way. I can certainly add
that.
I added your suggestions to my todo list.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
