[Dev] Action items from collections code/design review

[Ted Leung]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20050919/04bd9b19/attachment.htm