----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3486/#review11932 -----------------------------------------------------------
Ship it! Ship It! - Marquis On May 2, 2014, 7:26 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3486/ > ----------------------------------------------------------- > > (Updated May 2, 2014, 7:26 p.m.) > > > Review request for Asterisk Developers and Russell Bryant. > > > Bugs: ASTERISK-22372 > https://issues.asterisk.org/jira/browse/ASTERISK-22372 > > > Repository: Asterisk > > > Description > ------- > > This patch fixes res_corosync such that it works with Asterisk 12. This > restores the functionality that was present in previous versions of Asterisk, > and ensures compatibility with those versions by restoring the binary message > format needed to pass information from/to them. > > The following changes were made in the core to support this: > * The event system has been partially restored. All event definition and > event types were pulled from Asterisk 11. Previously, we had hoped that this > information would live in res_corosync; however, this approach seems to be > better for a few reasons: > (1) Theoretically, ast_events can be used by any module as a binary > representation of a Stasis message. Given the structure of an ast_event > object, that information has to live in the core to be used universally. For > example, defining the payload of a device state ast_event in res_corosync > could result in an incompatible device state representation in another module. > (2) Much of this representation already lived in the core, and was not > easily extensible. > (3) The code already existed. :-) > * Stasis message types now have a message formatter that converts their > payload to an ast_event object. > * Stasis message forwarders now handle forwarding to themselves. Previously > this would result in an infinite recursive call. Now, this simply creates a > new forwarding object with no forwards set up (as it is the thing it is > forwarding to). This is advantageous for res_corosync, as returning NULL > would also imply an unrecoverable error. Returning a subscription in this > case allows for easier handling of message types that are published directly > to an aggregate topic that has forwarders. > > > Diffs > ----- > > /branches/12/res/res_corosync.c 413035 > /branches/12/main/stasis_message.c 413035 > /branches/12/main/stasis.c 413035 > /branches/12/main/event.c 413035 > /branches/12/main/devicestate.c 413035 > /branches/12/main/app.c 413035 > /branches/12/include/asterisk/stasis.h 413035 > /branches/12/include/asterisk/event_defs.h 413035 > /branches/12/include/asterisk/event.h 413035 > /branches/12/include/asterisk/devicestate.h 413035 > > Diff: https://reviewboard.asterisk.org/r/3486/diff/ > > > Testing > ------- > > Verified the following between a cluster with two Asterisk 12 systems and a > cluster with an Asterisk 12 system and an Asterisk 11 system: > * Pinging back and forth > * MWI changes (publish and subscribe) > * Device state changes (publish and subscribe) > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
