> On Nov. 21, 2013, 12:59 a.m., Paul Belanger wrote: > > Thanks for this, I plan to spend some time over the weekend trying this > > out. My comments are mostly from the ARIs POV, specifically what is a > > device in ARI? and is that the same as an endpoint?
I'd akin this more to a "virtual generic entity/device". It's not a real device, and it's certainly not an endpoint you can dial. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3025/#review10226 ----------------------------------------------------------- On Nov. 20, 2013, 10:25 p.m., Kevin Harwell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3025/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2013, 10:25 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 402915 > branches/12/rest-api/api-docs/events.json 402915 > branches/12/rest-api/api-docs/device_states.json PRE-CREATION > branches/12/rest-api/api-docs/applications.json 402915 > branches/12/res/stasis/app.c 402915 > 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 402915 > branches/12/res/res_ari_device_states.c PRE-CREATION > branches/12/res/ari/resource_device_states.c PRE-CREATION > branches/12/res/ari/resource_device_states.h PRE-CREATION > branches/12/res/ari/resource_applications.h 402915 > branches/12/res/ari/ari_model_validators.c 402915 > branches/12/res/ari/ari_model_validators.h 402915 > branches/12/res/ari.make 402915 > branches/12/main/devicestate.c 402915 > branches/12/include/asterisk/stasis_app_device_state.h PRE-CREATION > branches/12/include/asterisk/stasis_app.h 402915 > branches/12/include/asterisk/devicestate.h 402915 > > 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