----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3025/#review10254 -----------------------------------------------------------
branches/12/include/asterisk/stasis_app.h <https://reviewboard.asterisk.org/r/3025/#comment19605> If this is going to be exposed globally, it needs to be renamed. branches/12/include/asterisk/stasis_app.h <https://reviewboard.asterisk.org/r/3025/#comment19603> There's no need to forward declare this a second time. branches/12/res/res_stasis_device_state.c <https://reviewboard.asterisk.org/r/3025/#comment19613> Why not search via OBJ_SEARCH_KEY? This seems like a pretty expensive operation when it doesn't have to be. - opticron On Nov. 21, 2013, 1:12 p.m., Kevin Harwell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3025/ > ----------------------------------------------------------- > > (Updated Nov. 21, 2013, 1:12 p.m.) > > > Review request for Asterisk Developers, David Lee and Matt Jordan. > > > Bugs: ASTERISK-22838 > https://issues.asterisk.org/jira/browse/ASTERISK-22838 > > > Repository: Asterisk > > > Description > ------- > > Created a data model and implemented functionality for an ARI device state > resource. The following operations have been added that allow a user to > manipulate an ARI controlled device: > > PUT /device-states/{deviceName}&{deviceState} - Create/Change the state of > an ARI controlled device > GET /device-states/{deviceName} - Retrieve the current state of a device > DELETE /device-states/{deviceName} - Destroy a device-state controlled by ARI > > The ARI controlled device must begin with 'Stasis:'. An example controlled > device name would be Stasis:Example. > > A 'DeviceStateChanged' event has also been added so that an application can > subscribe and receive device change events. Any device state, ARI controlled > or not, can be subscribed to. > > While adding the event, the underlying subscription control mechanism was > refactored so that all current and future resource subscriptions would be the > same. Each event resource must now register itself in order to be able to > properly handle [un]subscribes. > > > Diffs > ----- > > branches/12/rest-api/resources.json 402955 > branches/12/rest-api/api-docs/events.json 402955 > branches/12/rest-api/api-docs/deviceStates.json PRE-CREATION > branches/12/rest-api/api-docs/applications.json 402955 > branches/12/res/stasis/app.c 402955 > branches/12/res/res_stasis_device_state.exports.in PRE-CREATION > branches/12/res/res_stasis_device_state.c PRE-CREATION > branches/12/res/res_stasis.c 402955 > branches/12/res/res_ari_deviceStates.c PRE-CREATION > branches/12/res/ari/resource_deviceStates.c PRE-CREATION > branches/12/res/ari/resource_deviceStates.h PRE-CREATION > branches/12/res/ari/resource_applications.h 402955 > branches/12/res/ari/ari_model_validators.c 402955 > branches/12/res/ari/ari_model_validators.h 402955 > branches/12/res/ari.make 402955 > branches/12/main/devicestate.c 402955 > branches/12/include/asterisk/stasis_app_device_state.h PRE-CREATION > branches/12/include/asterisk/stasis_app.h 402955 > branches/12/include/asterisk/devicestate.h 402955 > > Diff: https://reviewboard.asterisk.org/r/3025/diff/ > > > Testing > ------- > > Some basic testing done using the swagger framework and a websocket > connection. Testing adding, changing, and removing device state with regards > to an ARI controlled device were successful. Also tested [un]subscribing to > the events from device with success. Planning on writing some testsuite test > cases as well. > > > Thanks, > > Kevin Harwell > >
-- _____________________________________________________________________ -- 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