[asterisk-app-dev] Blinky Lights Proposal

[Daniel Jenkins]

On 11 Nov 2013 15:36, "Matthew Jordan" <mjordan at digium.com> wrote:
>
>
> 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.

+1 to second option, much more api like

>
> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131111/c55516fb/attachment.html>