[Dev] collections and notifications

Ted Leung twl at osafoundation.org
Fri Mar 10 17:49:59 PST 2006

Andi Vajda wrote:
> On Thu, 9 Mar 2006, Alec Flett 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?

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?

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?

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.


More information about the chandler-dev mailing list