[Dev] Problem with collection notifications

[Phillip J. Eby]

At 10:30 AM 9/24/2005 -0700, John Anderson wrote:
>In many cases, for example when updating the UI, we change data which will 
>eventually cause a notification,

Why is the UI changing data?  Do you mean that it's changing blocks, or do 
you mean that user data is actually being changed?  If the UI is changing 
any data other than UI objects, we need to fix it or at least have a plan 
for how we're going to fix it.

If it's just that you're receiving notifications about changes to the UI 
objects, then we need to investigate why either:

1. notifications are being issued even when the data hasn't actually been 
changed, or

2. the UI is changing data in a way that doesn't converge to a fixed point 
(where no further changes are needed)

In short: none of the three ways I can think of to interpret your comments 
require temporarily ignoring notifications, because all three indicate that 
there is a bug in some part of the system.  Either the UI is broken 
(updating data it shouldn't be, or updating in a non-convergent way) or 
notifications themselves are broken (issuing redundant notifications for 
unchanged values).

In the simplest case, notifications shouldn't be issued if you set some 
attribute to a value it already has.  There are more complex cases that can 
produce an end result of "not changed" even though there were intermediate 
changes, and I'm pretty sure nobody's coded up those cases, even if the 
"set to the same value" case is taken care of.  We need to find out which 
case is causing your problems, though.

So, in summary, it shouldn't be *necessary* to suppress notifications to 
work around a bug (or missing feature) in notifications, nor should it be 
*allowed* to suppress notifications in order to get away with doing things 
that shouldn't be being done, like modifying user data from UI code in 
response to notifications, or modifying UI data non-convergently.