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 first action item on the wiki page says cleaned up notification API...
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.
Something like this is definitely what I was thinking of.
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?
One question is do we really need a class or could we do with module variables/functions? When you say persisting asynchronous callbacks, do you mean persisting the subscriptions? Persisting the actual callback code? Or persisting unconsumed notifications?
Ted
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
|
