Separating notification channels ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Separating notification channels ?

DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI

Hi all,

 

In our implementation market data and evaluation date changes are propagated through the same channel (observers update methods).

As we are properly trying to handle properly the evaluation date changes this coupling is becoming more and more an hindrance (eg: the Capstripper can no longer notifying lazily its observers). What about having dedicated channels ? Though I’m sure that some of us have already thought about this solution but what about using boost signal library to implement the notification chain ? Any thoughts ?

François


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separating notification channels ?

Luigi Ballabio
On Fri, 2007-07-27 at 09:57 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> In our implementation market data and evaluation date changes are
> propagated through the same channel (observers update methods).
>
> As we are properly trying to handle properly the evaluation date
> changes this coupling is becoming more and more an hindrance (eg: the
> Capstripper can no longer notifying lazily its observers).

Can you elaborate? What is the problem?

>  What about having dedicated channels ? Though I’m sure that some of
> us have already thought about this solution but what about using boost
> signal library to implement the notification chain ? Any thoughts ?

Yes, we might have a look at Boost.signal. But it would be a rather
large refactoring, and lately I'm becoming more concerned with
finalizing a 1.0 release, which calls for more stability instead.
Frankly, I'd leave your suggestion for after a stable release.

Later,
        Luigi


--

Barker's Proof:
Proofreading is more effective after publication.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev