<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 5, 2013 at 12:26 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Tue, Nov 5, 2013 at 11:07 AM, David M. Lee <span dir="ltr"><<a href="mailto:dlee@digium.com" target="_blank">dlee@digium.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On Oct 31, 2013, at 7:58 PM, Matthew Jordan <<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>> wrote:<br>
<br><br></div></blockquote></div></div></div></div></blockquote><div><br></div><div style><snip></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div></blockquote></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>


<br>
I’m not familiar enough with the use cases to put together an API counterproposal.<br>
<br>
This seems like a big/important enough topic to get its own wiki page. So I started one: <a href="https://wiki.asterisk.org/wiki/x/YQ2UAQ" target="_blank">https://wiki.asterisk.org/wiki/x/YQ2UAQ</a><br>
<br></blockquote><div><br></div></div><div>I'll comment more there! </div></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></blockquote><div><br></div><div style>As an update to this thread:</div>
<div style><br></div><div style>We now have two competing proposals for 'blinky light' functionality in ARI.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>