<div dir="ltr"><div class="gmail_extra">On Fri, Oct 18, 2013 at 4:52 PM, Paul Albrecht <span dir="ltr"><<a href="mailto:palbrecht@glccom.com" target="_blank">palbrecht@glccom.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
On Oct 18, 2013, at 10:20 AM, "David M. Lee" <<a href="mailto:dlee@digium.com">dlee@digium.com</a>> wrote:<br>
<br>
> On Oct 18, 2013, at 9:27 AM, Paul Albrecht <<a href="mailto:palbrecht@glccom.com">palbrecht@glccom.com</a>> wrote:<br>
><br>
>>> 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.<br>

>>><br>
>><br>
>> 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.<br>

><br>
> That's exactly what we have. But the C code to do so is tedious, repetitive, and error prone.<br>
><br>
<br>
</div>No it's really not. I would expect the callback to be in the module responsible for the resource. if that's tedious, repetitive, and error prone the you should reconsider your design and implementation.<br>

<div class="im"><br>
> We made design decisions to provide (and some extent, enforce) API documentation for ARI. Generating C code from the API declarations was fairly simple, and helps to enforce consistency between the API declarations and the implementation.<br>

><br>
<br>
</div>I guess at this point I find myself question the decision to do ARI in the first place. What's it supposed to be doing and how is it an improvement over the existing asterisk interfaces?<br>
<div class=""><div class="h5"><br>
> --<br>
> David M. Lee<br>
> Digium, Inc. | Software Developer<br>
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
> Check us out at:  <a href="http://www.digium.com" target="_blank">www.digium.com</a>  & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
><br>
><br>
> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
>   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br><br></div></div></blockquote><div><br></div><div><br></div><div>Paul, can you answer the question in my email so we all know where we stand, as I've taken your email to mean something different to what other people have talked about. </div>
</div><br></div></div>