On Wed, 2008-09-03 at 15:20 -0400, Paul Mossman wrote: > > > From: Spitzer, Andy (BL60:9D30) > > Sent: September 3, 2008 2:27 PM > > > I'm aware of that issue. Here is what I was planning to solve it: > > > > Instead of sending the NOTIFY's right away, it will queue it > > up to be sent in 5 seconds. Every time an update for a given > > URL occurs, that entry on the queue will be canceled and a > > new one generated for 5 seconds from then. As long as > > updates keep arriving within the 5 second window, the NOTIFY > > will be held off. 5 seconds after the final update, the > > NOTIFY with the final count will be sent. > > > > In this way, batch updates will be collapsed into one NOTIFY > > (assuming they arrive withing 5 seconds of each other), and > > single updates will still occur quickly. > > Sounds good, thanks! > > 5s seems a tad on the long side though, since it'll add that much delay > in the set MWI being updated.
I suspect that 5 seconds will be long enough that some people will complain about it - I am always astonished at how much attention some people pay to how quickly "little red lights" change (or don't). > As long it's configurable (through a > file, not necessarily in the GUI.) NO NO NO. Configuration is EVIL. Fiddle with it in testing to find a good value and hard code it. If it turns out not to be good in the field, we'll change it or find some other strategy that works better in a future release. We can't hide our configuration parameters - we're Open Source, so it's no help to not document or expose them. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
