[Dev] notifications about the collection itself
john at osafoundation.org
Sat Sep 10 09:02:10 PDT 2005
I still think our notification story is pretty awkward -- it's confusing
to know when to use a monitor, when to use a notification, what is
synchronous, what is asynchronous, and what kind of changes cause which
kinds of notificaitons/monitors to fire and what the performance trade
offs are. I'm petty sure I don't have all the details straight in my
mind, so I suspect other people will be confused also.
Andi Vajda wrote:
>> Maybe we should get rid collection notifications and use monitors
>> instead since notification don't do what we need -- what do you think?
> I think collection notifications fill a specific need and monitors
> another more general need.
> - Ted and you invented collection notifications because you wanted to
> whenever an item belonging to a collection changed and you wanted
> code to
> react to these changes when the system was ready - asynchronously, for
> example when idle.
> Collection notifications are sent out when polling for changes.
It's confusing that some notifications are synchronous and some are
asynchronous (requiring polling). I'd prefer to always have synchronous
notifications -- because you can always turn them into asynchronous
notification if you want. Nothing about the way notificaitons works
today is UI specific -- it's only that the UI is a client of notifications.
> - Monitors are more general, are synchronous and don't depend on the
> UI. A
> monitor method is told about an attribute value change synchronously,
> immediately after it occurred. No polling is necessary. Monitors are
> dispatched by operation - 'set', 'remove', 'schema' at the moment -
> and by
> attribute name.
> Both devices have drawbacks:
> - Misusing or abusing collection notifications is going to cause us
> to create
> more collections than needed and is going to create unmet
> expectations as
> these are sent out from the UI only, asynchronously. UI-less unit
> for example will not have them.
> - On the other hand, abusing monitors is going to slow down the
> system as all
> monitors for a given (op, attributeName) tuple are invoked for
> every change
> to an attribute's value.
> I think both devices serve a purpose and should be used sparingly as
> they are both hard to debug and trace. Monitors fire sometimes when
> you least expect it and can be recursive. Collection notifications
> will sometimes not fire, also when you least expect it.
> Yet, both patterns, allow for some pretty convenient and powerful
> constructs, so, in a word, buyer beware, use the right tool for the
> right task.
> Now, to Alec's question. If I understood it right, Alec was asking to
> be told when the color of a colored collection changed, not when the
> color of an item in that collection changed, something quite
> different. Unless that collection - an item itself - belongs to a
> collection too, no collection notification is going to fire for that
> change. It seems that a simple monitor would be very well suited for
> this task.
I'd like to have the option to get notified about these kinds of changes.
> Yet another way to do solve Alec's problem is instead of defining a
> attribute on a collection item - I've argued many times in the past
> that it didn't belong there - one could use a mixin kind defining that
> attribute along with a mixin class with relevant code to react to
> changes to that 'color' attribute in an onValueChanged() hook method.
> This approach is by far the most efficient from an execution path
> It also seems that PJE's annotation API would make this trivial to
> implement from a developer's point of view.
I recently remembered that collections are contentItems because they are
displayed in the UI, consequently, they have UI attributes, like
displayName. I suspect it's going to be rare to have a collection that
would never be displayed in the UI
>> Andi Vajda wrote:
>>>> John/Ted -
>>>> So right now the way notifications work is if any items in a
>>>> get modified/etc, then a notification goes out to subscribers.
>>>> In the case of color, I'm actually interested in getting notified when
>>>> the 'color' attribute on the collection itself, not a member of the
>>>> collection, is changed. I can change it via a menu right now, but the
>>>> calendar code doesn't know the color changed, so it doesn't know to
>>>> what would you guys think about making notifications fire for both the
>>>> collection items, as well as changes to the collection itself?
>>> Don't use notifications for that, use a monitor.
>>> For example:
>>> class AlecsItem(Item):
>>> def aColorChangedSomewhere(self, op, item, attribute):
>>> if op == 'set' and isCollection(item) and attribute ==
>>> print 'gosh, a colored collection changed to', item.color
>>> Attach the monitor:
>>> Monitors.attach(alecsItemInstance, 'aColorChangedSomewhere',
>>> 'set', 'color')
>>> Et voila. Monitors are persistent so you only need to set this up once.
>>> Collection notifications, as implemented today, are a UI-only device
>>> fired from the wx event loop's OnIdle() method. They are
>>> asynchronous and rather heavy as they are broadcast all subscribers
>>> of a set, indiscriminately.
>>> Monitors are synchronous and broadcast only to items monitoring the
>>> given op/attribute combination.
More information about the Dev