[Dev] collections and notifications

[John Anderson]

Andi Vajda wrote:
>
> On Fri, 10 Mar 2006, Ted Leung wrote:
>
>>>> The "collection item notifications" seem to have a distinctly 
>>>> different API than the other notifications. instead of 
>>>> 'subscriber.watchXXX(item, ..., methodName)' it is in the form 
>>>> 'collection.notificationQueueSubscribe(subscriber)'
>>>>
>>>> Is there a reason it has this different API? The other methods are 
>>>> actual methods on the subscriber, rather than the item being 
>>>> subscribed to. Second, the other systems allow you to specify a 
>>>> method name, which seems quite valuable.. It seems like it would be 
>>>> nice to be consistent with the APIs across all the notification 
>>>> systems.
The original collection mechanism allow the subscriber to specify a 
method name by adding an attribute with the name of the method to the 
subscriber.

+1 for consistent API.
>>>
>>> No particular reason other than history. I've been wondering about 
>>> that myself. Maybe I'll add a watchQueue(collectionItem, methodName) 
>>> API....
>> I think that something like watchQueue would be a good idea.  Also, 
>> implementing transient subscriptions by indirecting of the itsView 
>> attribute is not very intuitive.  Could you have a transient version 
>> of the method or pass a flag as an argument?
+1 for a flag
>
> Hmm, dunno, I wanted to make it clear that it was for the view it was 
> called on...
>
>> On the collections API, you've switched a create at construction time 
>> model. Does this mean it will be impossible to restructure the 
>> collection tree, short of destroying a subtree and constructing an 
>> entirely new one?
>
> Yes, that will be impossible without destroying and re-constructing. 
> The way the code was written before wouldn't have worked anyway, the 
> hard part here is that when a collection tree is modified in place, a 
> large, potentially huge, number of notifications have to be sent 
> around (at least to maintain upstream indexes). None of that was in 
> place in the old code, except for the add/removeSource method in 
> collections.py, which is still there and still works as before. Once 
> we have a use case for such in-place collection structure rearranging, 
> beyond what is implemented and functional today, we can reconsider this.
I think we could get away with not sending any notifications when 
rearranging the collection tree and recompute everything after the 
rearrangement. Independent of whether or not the old code actually 
worked, I suspect not allowing rearrangement will end eventually end up 
biting us, but I don't think we should work on it until we end up with a 
use case.
>
>> In your post, the collections that you show descend from Collection 
>> but also need to have their __metaclass__ set to 
>> schema.CollectionClass, since this is always needed (if I understand 
>> correctly), is there a way to make it so that setting the 
>> __metaclass__ is unnecessary?
>
> This is only needed for concrete base Collection subclasses. For 
> example, in osaf/pim/collections.py, the collection classes defined 
> there need this __metaclass__ but any of their subclasses wouldn't.
>
> Basically, you need this __metaclass__ wherever you use __collection__.
> It is my understanding that __metaclass__ is not inherited to 
> subclasses, so it has to be specified wherever it is needed, that is, 
> wherever you use __collection__ as well, in other words, wherever you 
> declare the attribute that is going to contain the wrapped set or ref 
> collection value.
>
>> Finally, I understand that using an explicit __collection__ attribute 
>> is more general, but if you look at the way that collections are 
>> used, the application will probably never make use of that 
>> generality.   But now all the collection classes require passing 
>> tuples including __collection__ arguments, which makes for more 
>> boilerplate code in the common case.  It seems like there could be 
>> better defaults for the common cases.
>
> Actually, no. With the bi-directional abstract set I recently added, 
> it became even more important not to hardcode this value. The designer 
> of a collection item subclass needs to have control over the name of 
> the attribute the set/ref-collection value that is being wrapped.
>
> As for the boilerplate you're referring to, it could be removed if 
> only repository/item/Sets.py were to know about 
> repository/item/Collection.py. Consider that a bug :)
>
> Andi..
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev