At the collections review we talked about some dimensions of notification
like systems. I'm going to rehash that as context for the rest of this
message.
1. Sync versus Async - when does the message get generated? As soon as a
change happens (synchronous) or is there some delay before the message is
generated (asynchronous)
2. Push versus Pull (poll) - How does the application get the message?
Callbacks are called when the message is generated? (push) Callbacks are
called when the application indicates it is ready to process the
notifications -- by calling some function (pull)
3. Transient versus Persistent - How is subscription information (who will
be notified of changes) maintained?
I'll point out that I don't think that it is necessary that we support all
possible combinations of dimensions. This is more just to help people
understand the design space of possibilities.
In Chandler, we have severals ways in which the app can be notified of
changes
1. Collection Notifications
* These tell you about the contents of a collection - when items are
added and removed from collections and when items in a collection are
changed.
* An item can subscribe to changes on a collection by adding itself to
that collection's subscribers list and implementing an onCollectionEvent
callback method
* When an add/remove operation happens a notification message is
generated and delivered to the callbacks of all subscribers
* When an item in the collection is changed, a notification message is
generated but is not delivered until mapChangesCallable is called. In
Chandler this happens in the idle loop
* This mix between sync/push and async/pull models within the
collections framework is problematic -- see below for a proposed solution.
* You can change the method which will be called as a callback by
adding an onCollectionEventHandler attribute (whose value is the name of
the method). It's not clear to me that we need this level of generality
* The callback API for collections has been propagated up from the low
level set API. This should probably be changed to something that doesn't
expose the implementation details of collections.
2. Monitors
* Monitors tell you about changes to any attribute named 'x',
regardless of the kind of the item.
* When you create a monitor you supply a callback which consists of an
item and a method on that item.
* When the the attribute is changed, the monitor code calls the
callback -- Message generation is synchronous and message delivery is push
based.
So there are a few problems that we need to look at.
1. the mix of notification styles in the collections framework
2. different mechanism for registering callbacks
3. differing callback API's
== Problem #1: the mix of notification styles
We agreed at the review that we would like to have a single style for
notifications. The driving consideration is for the app to be able to
process notifications when it is ready to, which points to a pull/polling
style model.
I have succeeded in restructuring the notification code so that all
notifications (add/remove/changed) are delivered when a single function is
called. Even though some messages are generated synchrounously, they are
queued until delivery, so as far as the application is concerned,
notifications are now delivered push style, which makes it hard to tell
whether the messages were generated synchronously or not. This function is
a module function in osaf.pim.collections:
deliverNotifications(repositoryView)
You must pass the current view to deliverNotifications, since changes
happen in a particular view. On possible improvement would be to make
deliverNotificaitons a method on a repositoryView, but I don't know how
Andi would feel about that, and I'm not convinced that would be an
improvement.
I have not checked this code in, but it is passing all the existing
notification tests, and Chandler appears to be running smoothly.
Every view has a notification queue (transient) attached to it, and
deliverNotifications walks the queue delivering the messages. Now that we
have the queue, it seems like this would be a good place to insert code to
completely turn off notifications, or to try to eliminate duplicate
notifications.
== Problem #2: Differing callback registration
Alec proposed a unified API for callback registration in the message below,
but needing to understand the possible values for 3 parameters seems more
complicated than calling the existing monitor and collections subscription
API's, although I suppose I could be persuaded.
== Problem #3: Differing callback APIs'
The API's for collection callbacks and monitor callbacks methods are
different.
collection_callback(self, op, item, name, other, *args)
op = the kind of change
item = the item containing a set (the collection item)
name = the name of the set attribute (always "rep" for collections)
other = the item that was changed
*args = grab bag, but mostly unused
monitor_callback(self, op, item, attribute, *args)
op = the kind of change
item = the item changed
attribute = the attribute that was changed (allowing you to use the
callback for more than one monitor if you checked the attribute value)
*args = grab bag
You could make them more similar by:
unified_callback(self, op, changedItem, changedValue, attribute=None,
*args)
For collections, attribute would be None, dropping the name is fine
because it is a fixed value in the collections framework.
For monitors, attribute would be the attribute that would be changed.
Again, it's not clear how much work this actually saves. But I am open to
suggestions
Ted
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
On Sep 19, 2005, at 1:56 PM, Alec Flett wrote:
Also, didn't we talk about a unified notification API that sits on top of
the Monitors/watchers/notifications with similar callbacks and all that
sort of thing?
The way I was imagining this was a singleton notification manager class
that has a single entrypoint for notification registration. It would also
be responsible for queuing up notifications, and would have a method that
"fires" these notifications that could be called from an OnIdle loop.
What's nice is that asynchronous notifications could be handled all in one
place, and it would be up to the front end's event loop to call the method
that "fires" the notifications, so all the notifications would originate
in the same place.
It would hopefully (if this isn't too ambitious) persist the async
notification list, and rely on the other subscription mechanisms (like
Monitors) to persist synchronous notification lists.
Here's some strawman code to get us started that uses Monitors and
Collection subscribers
class NotificationManager(...):
def QueueAsyncNotification(self, realTarget, realTargetMethod, ....):
def FireIdleNotifications(self, ...):
def RegisterCallback(self, targetItem, methodName, item=None,
attribute=None, synchronous=True):
if item is None:
if synchronous and attribute is not None:
Monitors.attach(target, methodName, 'set', attribute)
elsif isinstance(item, AbstractCollection):
if synchronous:
item.subscribers.add((targetItem, methodName))
else:
item.subscribers.add((self, 'QueueAsyncNotification', ..))
Now you could say
notificationManager.RegisterCallback(self, 'onMyCollectionChanged',
mycollection)
Obviously there are lots of combinations of item/attribute/synchronous
that we need to address here.. persisting asynchronous callbacks is going
to be tricky. We'd also need API changes (like that change to
AbstractCollection.subscribers) and callback parameter unification, but
its a start. What do people think?
Alec
Ted Leung wrote:
The action items that we agreed on at the collections code/design review
are here: <http://wiki.osafoundation.org/bin/view/Journal/
TedLeung20050912>
One of the items is to move away from use of onValueChanged and go back
to using constructors for creating various collection kinds.
Unfortunately, this
means that we wouldn't be able to use update to change existing
instances in the repository. So we can't remove the onValueChanged
stuff, so it doesn't
make sense to duplicate the code in the collection item constructors.
So I'm just going to leave the code the way that it is now.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
