Re: [Dev] Action items from collections code/design review

[Alec Flett]

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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev