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..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
