On Oct 17, 2013, at 10:37 AM, Matthew Jordan <mjordan at digium.com> wrote: > > On Thu, Oct 17, 2013 at 10:02 AM, Paul Albrecht <palbrecht at glccom.com> wrote: > > On Oct 17, 2013, at 9:28 AM, Paul Belanger <paul.belanger at polybeacon.com> wrote: > > > On Thu, Oct 17, 2013 at 10:22 AM, Paul Albrecht <palbrecht at glccom.com> wrote: > > I think you might be missing the concept of ARI, you wouldn't write > > your app in C to generate ARI resources. You'd write your application > > atop of ARI and consume them. > > > > 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. > > > 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. 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. > > The longer answer is what Paul B. is driving towards: what do you want to expose through ARI? > This is really irrelevant. What's at issue is the implementation. Any resource will do as an example if you need one. > 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). > 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. > What fundamental resource are you thinking of providing that is not already represented in Asterisk? 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. > > > Again, what sort of thing are you looking to do. > > > > 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? > > > 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. 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. > > -- > 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/20131017/380658ad/attachment-0001.html>
