[Dev] collections and notifications

[Andi Vajda]

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.
>> 
>> 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?

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.

> 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..