[Dev] Action items from collections code/design review
twl at osafoundation.org
Mon Sep 19 14:59:26 PDT 2005
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
> 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))
> 'QueueAsyncNotification', ..))
> Now you could say
> notificationManager.RegisterCallback(self, 'onMyCollectionChanged',
> 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 Leung wrote:
>> The action items that we agreed on at the collections code/design
>> review are here: <http://wiki.osafoundation.org/bin/view/Journal/
>> 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.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Dev" mailing list
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev