﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>MrMan commented on Pull vs. Push models for UI updates</title><description>Nesper? It does exactly what you describe. 
  
  
[http://esper.codehaus.org/about/nesper/nesper.html](http://esper.codehaus.org/about/nesper/nesper.html)  
  
Use this with retlang or CCR. 
  
  
Can anyone elaborate on the lineage of CCR from that Wintellect library? I was not aware of that.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment19</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment19</guid><pubDate>Mon, 23 Feb 2009 15:21:54 GMT</pubDate></item><item><title>Frans Bouma commented on Pull vs. Push models for UI updates</title><description>Sounds familiar (the problem). If you have an application which visualizes a model in various ways and reflects changes immediately, it can be slow when a lot of events are raised because of a single change (e.g. check a checkbox, which changes a property, which triggers a 'I'm changed!' event which bubbles through a model). 
  
  
You can solve it in different ways. The approach you took is OK if the UI has a single area which suffers from a lot of updates, so polling can make things simpler. It has a disadvantage: it only works in some situations, namely the ones where you know you'll get a lot of updates and you want to poll for them instead of observe the changes come in. It can be cumbersome to use it in other situations as your observer setup is more cumbersome (i.e. with timers, instead of an event handler). 
  
  
Another approach, which I took in llblgen pro v2, is the introduction of a different set of events for visualization. This too has downsides, though it makes writing ui code simpler: you write UI code to update itself against the visualization oriented events, not the regular changed events. It gives a much more fine-grained way to fine-tune performance with larger sets of events, as it's not the event system itself which is slow, but the messagepump wrapping in .NET.
  
  
Another approach is to use a flag for the event handling, and only accept calls to the event handlers if the flag is false, and it's managed by a timer. 
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment18</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment18</guid><pubDate>Tue, 17 Feb 2009 12:22:44 GMT</pubDate></item><item><title>Joe Gutierrez commented on Pull vs. Push models for UI updates</title><description>The complexity doesn't go away whether using push or pull. Just where you're encapsulating the complexity.
  
  
In "The Cost of Messaging" you used a pull method on the authentication service.
  
  
I think the polling mechanism required for a pull is complex. Which object is responsible for the polling? The UI?
  
  
I think you're breaking separation of responsibilities, if the UI is responsible for polling.
  
  
I think this is true: ". . . UI operations are expensive, while backend operations tend to be very cheap."
  
  
So try it keep the operations on the back-end
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment17</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment17</guid><pubDate>Mon, 16 Feb 2009 18:27:12 GMT</pubDate></item><item><title>Torkel commented on Pull vs. Push models for UI updates</title><description>I came to the same conclusion on my last WPF app, that is i moved some stuff (like updating stats) to a pull model that updated at regular intervals (I choose 0.5s too) . 
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment16</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment16</guid><pubDate>Mon, 16 Feb 2009 17:23:51 GMT</pubDate></item><item><title>Gena commented on Pull vs. Push models for UI updates</title><description>We also use a push driven (or event bubbling) approach and sometimes have the same situation when number of changes is too big. Since we use PostSharp to subscribe/bubble events I'm considering to group them inside the aspect when corresponding parameter is used, e.g.:
  
  
[BubbleEvents(Delay=0.5] // or also groupby parameters
  
public class A
  
{
  
   ...
  
}
  
  
For INotifyCollectionChanged it may work using OldItems, NewItems but for INotifyPropertyChanged something else should be invented ... INotifyPropertiesChanged, to specify many properties changed in the last 0.5 sec groupped by senders.
  
  
... or to define smth like MaxCapacity=100 [events/sec] :)
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment15</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment15</guid><pubDate>Mon, 16 Feb 2009 17:18:08 GMT</pubDate></item><item><title>Ayende Rahien commented on Pull vs. Push models for UI updates</title><description>Joe,
  
The problem is that the events that are going on are complex, you can do anything via push model.
  
Filtering on that is hard.
  
The pull method is generating a snapshot, so there is a lot less complexity.
  
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment14</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment14</guid><pubDate>Mon, 16 Feb 2009 16:57:57 GMT</pubDate></item><item><title>Dag Christensen commented on Pull vs. Push models for UI updates</title><description>Isn't 0.5 just a configurable number, like the low | normal | high update speed modes of windows task manager. On my work laptop I'd probably prefer "low" in a WPF app since otherwise the fan goes through the roof from the high load updating my gui.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment13</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment13</guid><pubDate>Mon, 16 Feb 2009 16:51:27 GMT</pubDate></item><item><title>Joe Gutierrez commented on Pull vs. Push models for UI updates</title><description>Why change from a push to a pull. As you stated a push is much simpler than a pull. Keep it! Just add an event filtering mechanism. This time a temporal filter.
  
  
I like this because when you register for the events you are already registering a filter of sorts, events that your presentation is interested in. So you might as well add a temporal filter too.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment12</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment12</guid><pubDate>Mon, 16 Feb 2009 16:26:06 GMT</pubDate></item><item><title>Ayende Rahien commented on Pull vs. Push models for UI updates</title><description>Peter,
  
.5 is not something that you would notice, in most cases.
  
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment11</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment11</guid><pubDate>Mon, 16 Feb 2009 14:19:13 GMT</pubDate></item><item><title>Peter Morris commented on Pull vs. Push models for UI updates</title><description>Just to be clear I my aim isn't "fast" but "immediate".  I just think that stepping through code and waiting up to .5 seconds for the log to come through is sluggish, especially if you are stepping through multiple lines of code and waiting for each log in order to find a specific problem.
  
  
Another way of putting it.  You could still throttle the updates to no more than X lines per second, but using a variable sleep based on the last update time + amount of data retrieved last time.
  
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment10</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment10</guid><pubDate>Mon, 16 Feb 2009 14:02:54 GMT</pubDate></item><item><title>Steve commented on Pull vs. Push models for UI updates</title><description>Thanks for the Retlang plug, I went to check it out and it is very good!
  
  
Can this be used in Silverlight apps?  (or is there any thought to include it in Silverlight?)
  
  
Sorry to highjack your post Ayende !
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment9</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment9</guid><pubDate>Mon, 16 Feb 2009 13:38:33 GMT</pubDate></item><item><title>Jonathan commented on Pull vs. Push models for UI updates</title><description>One thing that you have probably already implemented--or at least considered--is dumping all SQL statements to some kind of log file.  If the info is coming too fast for the UI, you can display a portion of the queries in the UI as mentioned in the post, but the user could easily go to a log file for the more complete account, e.g. perhaps to see if and how a single row of 10,000 was properly inserted.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment8</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment8</guid><pubDate>Mon, 16 Feb 2009 13:01:05 GMT</pubDate></item><item><title>Cosmin Onea commented on Pull vs. Push models for UI updates</title><description>Ayende, how about using the CCR for the UI update 
  
[http://channel9.msdn.com/pdc2008/TL55/](http://channel9.msdn.com/pdc2008/TL55/)  
You get your responsive UI. 
  
The drawback, it is not free. CCR is built from an idea that Jeff Ritcher had and sold it to Microsoft. Check his PowerThreading library out 
[http://www.wintellect.com/PowerThreading.aspx](http://www.wintellect.com/PowerThreading.aspx) (free library).
  
  
Cheers,
  
Cosmin
  
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment7</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment7</guid><pubDate>Mon, 16 Feb 2009 12:27:13 GMT</pubDate></item><item><title>Ayende Rahien commented on Pull vs. Push models for UI updates</title><description>Peter,
  
But I don't _want_ the data as fast as possible.
  
I want the data in human relative time.
  
Because it doesn't mean anything to display all the data.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment6</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment6</guid><pubDate>Mon, 16 Feb 2009 12:12:54 GMT</pubDate></item><item><title>Peter Morris commented on Pull vs. Push models for UI updates</title><description>Mike: That's exactly what I am trying to suggest Oren achieves by using a manual reset event, a thread pool job queued for that event, and the GUI requeuing the next wait when it has finished updating the GUI.
  
  
The first data will come through immediately, subsequent data will come through as quickly as the GUI can handle it without crippling Windows.
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment5</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment5</guid><pubDate>Mon, 16 Feb 2009 09:50:14 GMT</pubDate></item><item><title>Paul Stovell commented on Pull vs. Push models for UI updates</title><description>Ayende, how are you performing the data aggregation, filtering, etc.? Have you considered something like Bindable LINQ :) 
[www.codeplex.com/bindablelinq?](http://www.codeplex.com/bindablelinq?)</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment4</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment4</guid><pubDate>Mon, 16 Feb 2009 09:23:54 GMT</pubDate></item><item><title>Mike Rettig commented on Pull vs. Push models for UI updates</title><description>In other words, this is producer versus consumer pace. The UI wants the events at an appropriate pace for human consumption while the producer of the information simply wants to publish any and all updates. 
  
  
To plug Retlang one more time.... this is why Retlang works so well in the UI. Producers publish information at any rate that is appropriate, while consumers (UI threads) can choose the rate of delivery.  Subscriptions can be for the last message, for all messages over an interval, or for all unique events over an interval.  With multiple subscriptions, some parts of the UI are updated immediately while other information can operate on a delay.
  
  
I just added an example earlier today for WPF in SVN. 
  
  
Mike Rettig
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment3</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment3</guid><pubDate>Mon, 16 Feb 2009 04:00:40 GMT</pubDate></item><item><title>Ayende Rahien commented on Pull vs. Push models for UI updates</title><description>The UI is updated every .5 seconds.
  
Think about a reporting interface, where the values are constantly updating.
  
For example:
  
  
number of sessions: 15
  
number of alerts: 312
  
avg. statements per session: 23.4
  
avg. alerts per session :12.1
  
  
Or seeing new rows added to grid 
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment2</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment2</guid><pubDate>Mon, 16 Feb 2009 03:45:01 GMT</pubDate></item><item><title>configurator commented on Pull vs. Push models for UI updates</title><description>So now the user has an interface that is changed every .5 seconds? How does that work, in terms of usability?
</description><link>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment1</link><guid>http://ayende.com/3877/pull-vs-push-models-for-ui-updates#comment1</guid><pubDate>Mon, 16 Feb 2009 03:34:33 GMT</pubDate></item></channel></rss>