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>
