<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 17, 2013, at 10:37 AM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 17, 2013 at 10:02 AM, Paul Albrecht <span dir="ltr"><<a href="mailto:palbrecht@glccom.com" target="_blank">palbrecht@glccom.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Oct 17, 2013, at 9:28 AM, Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>> wrote:<br>
<br>
> On Thu, Oct 17, 2013 at 10:22 AM, Paul Albrecht <<a href="mailto:palbrecht@glccom.com">palbrecht@glccom.com</a>> wrote:<br>> I think you might be missing the concept of ARI, you wouldn't write<br>
> your app in C to generate ARI resources. You'd write your application<br>
> atop of ARI and consume them.<br>
><br>
<br>
</div>I'm talking about third party asterisk modules that may need to expose their resources to applications that manage asterisk via the AMI/CLI. They may need to expose their resources so that an application can manage their resources.<br>
<div class="im"><br></div></blockquote><div><br></div><div style="">The short answer is yes: ARI is extensible. Both the RESTful interface as well as the JSON events can be extended via shared object libraries.</div></div></div></div></blockquote><div><br></div><div>OK, How do I register/unregister a resource? Do I have to recompile asterisk if I change the resource? If there isn't an interface to register/unregister resources and I have to recompile asterisk to make changes then the implementation isn't extensible and modular as are the CLI and AMI interfaces.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">
<br></div><div style="">The longer answer is what Paul B. is driving towards: what do you want to expose through ARI?</div><div style=""><br></div></div></div></div></blockquote><div><br></div><div>This is really irrelevant. What's at issue is the implementation. Any resource will do as an example if you need one.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">ARI's current purpose is to provide raw communications objects to application developers so that they can build their own applications. These concepts are generally fundamental to Asterisk: things like bridges, channels, endpoints, and the like. If I'm a third party and I've written my own channel driver, I'm already going to be represented under the channels resource (you may have to do a bit of work to integrate yourself as an endpoint, but again, there are APIs for that).</div>
<div style=""><br></div></div></div></div></blockquote><div><br></div><div>Here you beg the question, that is, if it's not "fundamental" then there's no requirement. It seems to me that if you're going to put out a new interface to control asterisk then it should be extensible and modular which means in turn it should apply to third party modules.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">What fundamental resource are you thinking of providing that is not already represented in Asterisk?</div></div></div></div></blockquote><div><br></div><div>Doesn't make any difference. Again, pick your own example if it helps you get your head around the problem. It's the implementation of ARI that's at issue.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style=""> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Again, what sort of thing are you looking to do.<br>
><br>
<br>
</div>Don't have a specific scenario for you. I'm just asking. It really should be obvious. The ARI should be extendible as are the CLI and AMI interfaces. If they're not, the what's explanation/rationale?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div> </div><div style="">And if the answer to my question is "I don't know, but I just wanted to know if the option is there", then yes, the option is there to extend the API.</div></div></div></div></blockquote><div><br></div><div>The answer is evidently *no* because the implementation of ARI isn't modular or extensible as I assume there is no interface to register/unregister resources and you have to recompile asterisk if you need to change a resource. This is obviously different than the way CLI and AMI are implemented so one naturally wonders what is explanation/rationale for this change.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> <br></div></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>
_______________________________________________<br>asterisk-app-dev mailing list<br><a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev<br></blockquote></div><br></body></html>