[asterisk-app-dev] Blinky Lights Proposal

[Matthew Jordan]

On Tue, Nov 5, 2013 at 12:26 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
> On Tue, Nov 5, 2013 at 11:07 AM, David M. Lee <dlee at digium.com> wrote:
>
>>
>> On Oct 31, 2013, at 7:58 PM, Matthew Jordan <mjordan at digium.com> wrote:
>>
>>
>>
<snip>


>
>
>>
>> I at least like to see what individual /mailboxes, /devicestates, and
>> /presencestates resource would like like before we attempt to combine them
>> at the API level. If we find that these are three different names for
>> identical API’s, then maybe merging them is a good idea. But my gut tells
>> me that we’ll find subtle differences between them.
>>
>> I’m not familiar enough with the use cases to put together an API
>> counterproposal.
>>
>> This seems like a big/important enough topic to get its own wiki page. So
>> I started one: https://wiki.asterisk.org/wiki/x/YQ2UAQ
>>
>>
> I'll comment more there!
>
>
As an update to this thread:

We now have two competing proposals for 'blinky light' functionality in ARI.

The first is what was proposed initially in this e-mail thread. ARI would
contain a very generic resource that would allow users to manipulate the
state of a subscribable topic. This approach has the benefit of being very
flexible for future expansion of additional subscriable entities, at the
cost of being an opaque API; that is, what an entity is can only be known
from documentation.

The second is proposed on the wiki page linked in the previous e-mails. ARI
would contain specific resources for each subscriable entity, i.e., a
resource for MWI, for device state, etc. This makes it very clear what is
available, at the cost of a minor amount of redundancy.

In the end, after looking at both, I agree with David's approach more than
mine own. The benefit of the second - other than being more RESTful - is
clear from the perspective of someone approaching ARI and wanting an
intuitive interface. Behind the scenes, there are enough differences with
the various things that can be subscribed/published that having separate
resources in the interface also makes sense. Finally, David's approach
doesn't really limit the flexibility of the interface: since the
implementation of each resource can live in separate modules, adding a new
thing that can be subscribed/published to only really impacts the data
model itself.

Barring any major out cry from anyone, I think we're going to start work on
this second approach, probably with device state initially. There's some
rough edges to MWI (particularly in whether or not we want ARI to have any
overlap with the voicemail provider API in app.h) that need to be thought
through still.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131111/07370717/attachment.html>