[KCP] Thoughts on adding system changes and refactoring ChangeSet

Stephen Pair stephen at pairhome.net
Tue Jun 24 21:10:20 UTC 2003


Avi Bryant wrote:

>On Tue, 24 Jun 2003, Stephen Pair wrote:
>
>  
>
>>As an example, the browser might poll the currently selected class and
>>category for a list of methods to display in the right most list box, it
>>would do this often enough that a change to this list elsewhere would be
>>reflected in the browser in a timely manner.  If the entire browser or
>>the affected portions of the browser (method list and source pane) are
>>obscurred by other morphs, then the browser need not poll for that list
>>of methods.
>>    
>>
>
>Stephen,
>
>This might work for browsers, but the vast majority of the clients of the
>notification system (ChangeSet, packaging and versioning systems, analysis
>tools, other dev tools like MessageLists)  won't work (or will be
>extremely slow) in a polling system.  Polling only works when the set of
>methods you are looking at happens to be well indexed (eg, all the methods
>in a certain category of a certain class).  Most sets of methods a tool is
>interested in (eg, all the methods that have changed recently, or all the
>methods that send #foo) require linear search to discover.  You could add
>more indices, of course, but maintaining them requires a notification
>system...
>
>Avi
>  
>
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)

One thing that bothers me about notification systems is that you have to anticipate in advance what events someone might be interested in.  I've seen this taken to an extreme in some systems to the point where every setter in the system triggers an event.  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.

I'm not saying that notification systems should not used, or that polling should be used exclusively...just that maybe there is some balance to be found, or some better system to be invented.  Maybe the polling solution and the notification solution are two opposite extremes out of which a common implementation that accomodates both approaches could be created.

- Stephen





More information about the Squeak-dev mailing list