[asterisk-dev] [Code Review] 2672: Split caching out from the stasis_caching_topic

[opticron]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2672/#review9239
-----------------------------------------------------------



/trunk/include/asterisk/stasis_cache_pattern.h
<https://reviewboard.asterisk.org/r/2672/#comment18222>

    a -> an



/trunk/include/asterisk/stasis_cache_pattern.h
<https://reviewboard.asterisk.org/r/2672/#comment18223>

    This should mention that the topics obtained from this function are (should be) the ingress point for all channel-specific messages into this caching pattern.



/trunk/include/asterisk/stasis_endpoints.h
<https://reviewboard.asterisk.org/r/2672/#comment18224>

    Should this be marked internal?


- opticron


On July 26, 2013, 11:51 a.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2672/
> -----------------------------------------------------------
> 
> (Updated July 26, 2013, 11:51 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22002
>     https://issues.asterisk.org/jira/browse/ASTERISK-22002
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> In working with res_stasis, I discovered a significant limitation to
> the current structure of stasis_caching_topics: you cannot subscribe
> to cache updates for a single channel/bridge/endpoint/etc.
> 
> To address this, this patch splits the cache away from the
> stasis_caching_topic, making it a first class object. The stasis_cache
> object is shared amongst individual stasis_caching_topics that are
> created per channel/endpoint/etc. These are still forwarded to global
> whatever_all_cached topics, so their use from most of the code does
> not change.
> 
> In making these changes, I noticed that we frequently used a similar
> pattern for bridges, endpoints and channels:
> 
>      single_topic  ---------------->  all_topic
>            ^
>            |
>      single_topic_cached  ----+---->  all_topic_cached
>                               |
>                               +---->  cache
> 
> This pattern was extracted as the 'Stasis Caching Pattern', defined in
> stasis_caching_pattern.h. This avoids a lot of duplicate code between
> the different domain objects.
> 
> Since the cache is now disassociated from its upstream caching topics,
> this also necessitated a change to how the 'guaranteed' flag worked
> for retrieving from a cache. The code for handling the caching
> guarantee was extracted into a 'stasis_topic_wait' function, which
> works for any stasis_topic.
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_meetme.c 394263 
>   /trunk/apps/app_voicemail.c 394263 
>   /trunk/apps/confbridge/confbridge_manager.c 394263 
>   /trunk/channels/chan_dahdi.c 394263 
>   /trunk/channels/chan_gulp.c 394263 
>   /trunk/channels/chan_iax2.c 394263 
>   /trunk/channels/chan_mgcp.c 394263 
>   /trunk/channels/chan_sip.c 394263 
>   /trunk/channels/chan_unistim.c 394263 
>   /trunk/channels/sig_pri.c 394263 
>   /trunk/include/asterisk/app.h 394263 
>   /trunk/include/asterisk/bridging.h 394263 
>   /trunk/include/asterisk/channel.h 394263 
>   /trunk/include/asterisk/channel_internal.h 394263 
>   /trunk/include/asterisk/devicestate.h 394263 
>   /trunk/include/asterisk/presencestate.h 394263 
>   /trunk/include/asterisk/stasis.h 394263 
>   /trunk/include/asterisk/stasis_bridging.h 394263 
>   /trunk/include/asterisk/stasis_cache_pattern.h PRE-CREATION 
>   /trunk/include/asterisk/stasis_channels.h 394263 
>   /trunk/include/asterisk/stasis_endpoints.h 394263 
>   /trunk/main/app.c 394263 
>   /trunk/main/bridging.c 394263 
>   /trunk/main/cdr.c 394263 
>   /trunk/main/cel.c 394263 
>   /trunk/main/channel_internal_api.c 394263 
>   /trunk/main/cli.c 394263 
>   /trunk/main/devicestate.c 394263 
>   /trunk/main/endpoints.c 394263 
>   /trunk/main/manager.c 394263 
>   /trunk/main/manager_bridging.c 394263 
>   /trunk/main/manager_channels.c 394263 
>   /trunk/main/manager_endpoints.c 394263 
>   /trunk/main/pbx.c 394263 
>   /trunk/main/presencestate.c 394263 
>   /trunk/main/stasis.c 394263 
>   /trunk/main/stasis_bridging.c 394263 
>   /trunk/main/stasis_cache.c 394263 
>   /trunk/main/stasis_cache_pattern.c PRE-CREATION 
>   /trunk/main/stasis_channels.c 394263 
>   /trunk/main/stasis_endpoints.c 394263 
>   /trunk/main/stasis_wait.c PRE-CREATION 
>   /trunk/res/res_agi.c 394263 
>   /trunk/res/res_chan_stats.c 394263 
>   /trunk/res/res_jabber.c 394263 
>   /trunk/res/res_sip_mwi.c 394263 
>   /trunk/res/res_stasis.c 394263 
>   /trunk/res/res_xmpp.c 394263 
>   /trunk/res/stasis/control.c 394263 
>   /trunk/res/stasis_http/resource_bridges.c 394263 
>   /trunk/res/stasis_http/resource_channels.c 394263 
>   /trunk/res/stasis_http/resource_endpoints.c 394263 
>   /trunk/tests/test_cel.c 394263 
>   /trunk/tests/test_devicestate.c 394263 
>   /trunk/tests/test_stasis.c 394263 
>   /trunk/tests/test_stasis_endpoints.c 394263 
> 
> Diff: https://reviewboard.asterisk.org/r/2672/diff/
> 
> 
> Testing
> -------
> 
> Tests pass.
> 
> 
> Thanks,
> 
> David Lee
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130729/9d04dd1a/attachment-0001.htm>