Commit Graph

3 Commits

Author SHA1 Message Date
Kevin Harwell
99d5cb8555 ARI: Implement device state API
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:

Create/Change the state of an ARI controlled device
PUT    /deviceStates/{deviceName}&{deviceState}

Retrieve all ARI controlled devices
GET    /deviceStates

Retrieve the current state of a device
GET    /deviceStates/{deviceName}

Destroy a device-state controlled by ARI
DELETE /deviceStates/{deviceName}

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.

(issue ASTERISK-22838)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3025/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@403134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:38:29 +00:00
David M. Lee
2f92695c22 ari: User better nicknames for ARI operations
While working on building client libraries from the Swagger API, I
noticed a problem with the nicknames.

    channel.deleteChannel()
    channel.answerChannel()
    channel.muteChannel()

Etc. We put the object name in the nickname (since we were generating C
code), but it makes OO generators redundant.

This patch makes the nicknames more OO friendly. This resulted in a lot
of name changing within the res_ari_*.so modules, but not much else.

There were a couple of other fixed I made in the process.

 * When reversible operations (POST /hold, POST /unhold) were made more
   RESTful (POST /hold, DELETE /unhold), the path for the second operation
   was left in the API declaration. This worked, but really the two
   operations should have been on the same API.
 * The POST /unmute operation had still not been REST-ified.

Review: https://reviewboard.asterisk.org/r/2940/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@402528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-07 21:09:18 +00:00
David M. Lee
cd2ddccaf2 Added missing file from r400522
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-04 19:31:35 +00:00