[KCP] Thoughts on adding system changes and refactoring ChangeSet

Andreas Raab andreas.raab at gmx.de
Tue Jun 24 23:17:04 UTC 2003


Stephen,

> If the operation puts a heavy load on the system, then I 
> don't think you should force that on a user no matter what 
> the auto-update mechanism is.  Better to use a "refresh" 
> button in those cases (or name the button "Run Query" if 
> "refresh" is a turn off ;)).  When I accept a method, I 
> wouldn't want that to take an extra 20 seconds because it's 
> told 10 different GUIs to update long and complicated queries.
> 
> (Keep in mind that a polling solution (such as morphic) can 
> dynamically adjust the polling interval based on how long a 
> cycle takes to compute)

So can an event driven mechanism. It just has to measure how long it takes.

> One thing that bothers me about notification systems is that 
> you have to anticipate in advance what events someone might 
> be interested in.

Unless, of course, you can derive the events dynamically - which in fact is
*very* doable up to a certain point. After which you can still fall back on
polling and do this invisibly if you want. What you really need here is an
understanding of where the tradeoffs for events vs. polling are - if you
have some sort of "uncertainty principle" (e.g., you cannot observe when
EXACTLY something happened) then polling and events are interchangeable and
can be treated uniformly. Up to the point that you can use a condition as an
event.

> I've seen this taken to an extreme in some 
> systems to the point where every setter in the system 
> triggers an event.

And they should! A state change of some property or other is about the first
thing you want to watch for (in Tweak all variable stores generate an event
- this happens automatically so the programmer isn't burdened by it and you
can simply say "do this when that variable changes its value").

> As these systems grow more complex, you 
> start to run into very complex event timing scenarios, 
> endless event propogation loops, and the like.  It would be 
> nice if we could come up with a more general, loosly coupled, 
> and good performing system.

Do you have any first-hand experience with those problems? I'd be
interesting in chatting about this a little more. So far, the only real
issue I've found was "delayed state propagation" and I'm going to do
something about this (it's quite simple, I just haven't got around doing
it).

Cheers,
  - Andreas



More information about the Squeak-dev mailing list