On Oct 17, 2013, at 1:58 PM, "David M. Lee" <dlee at digium.com> wrote:
>
> On Oct 17, 2013, at 1:23 PM, Paul Albrecht <palbrecht at glccom.com> wrote:
>
>>
>> On Oct 17, 2013, at 11:01 AM, David M. Lee <dlee at digium.com> wrote:
>>
>>>
>>> On Oct 17, 2013, at 9:29 AM, Paul Albrecht <palbrecht at glccom.com> wrote:
>>>
>>>> Is the ARI extendible as are other asterisk user interfaces like the CLI and AMI. That's the question. If not, why not?
>>>
>>>
>>> Sort of. It's designed to be modular and allow for extension, but it's not great for external module developers yet.
>>>
>>> The current process is:
>>>
>>> 1. Write a new API declaration (rest-api/api-docs/fizzbin.json)
>>> 2. Add your declaration to the master list (rest-api/resources.json)
>>> 3. Run 'make ari-stubs'
>>>
>>> This will generate several files.
>>> * res/res_ari_fizzbin.c - Boiler plate code for parsing HTTP request, validating responses, etc.
>>> * res/ari/resource_fizzbin.h - Boiler plate header file
>>> * res/ari/resource_fizzbin.c - Implementation stubs
>>>
>>> It will also update res/ari/ari_model_validators.h and res/ari/ari_model_validators.c with validators for your data models.
>>>
>>> The res/ari/resource_fizzbin.c is the only one you modify. This is where you would implement your RESTful API.
>>>
>>> I have a short list (in my head) of the changes that would be necessary to enable external ARI modules.
>>>
>>> * Allow make_ari_stubs.py to be run against a single API declaration
>>> * In this case, model generators should be embedded in the module, instead of being put in res_ari_model.c
>>> * Embed the API declaration in the generated res/res_ari_fizzbin.c
>>> * Serve /ari/api-docs out of the modules instead of from the filesystem
>>> * Build /ari/api-docs/resource.json dynamically from what's loaded instead of from the filesystem
>>>
>>
>> Thanks for the info. Maybe it should be in the wiki.
>
> I've put my wish-list to enable external ARI modules on my (newly created) ARI future work page[1].
>
>> That said, I would expect an interface to register/unregister resource. Also, changing a resource shouldn't require recompiling asterisk.
>
> It doesn't require recompiling Asterisk; the C code is modular. But the code generator needs some love in order to make this work well. (Hence my short list for ARI future work).
>
> As far as registering a resource with ARI, the main function is ast_ari_add_handler()[2]. That call, and the code to build the stasis_rest_handlers tree that gets passed into it, resides in the generated res/res_ari_{resource}.c file.
Suppose this will work, but why not implement resources the usual way asterisk does this sort of thing? That is, create an object via a registration interface and then call the methods on the object when they're needed. For resources, it would be something like register the uri and callbacks for the rest methods and then invoke the methods via the object when then accessed.
>
> [1]: https://wiki.asterisk.org/wiki/x/mQeUAQ
> [2]: http://doxygen.asterisk.org/trunk/d4/d59/ari_8h.html#d960fe775504c2df60bcb7f7f9beb5b2
>
> --
> David M. Lee
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: www.digium.com & www.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
