<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/4437/">https://reviewboard.asterisk.org/r/4437/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On February 26th, 2015, 10:46 a.m. CST, <b>Joshua Colp</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><mjordan> file: for the proposed DNS API, are you envisioning having it act as a facade over a particular library? Or having a separate file/module register to the core?
<file> register
<file> the end result will be the same but it keeps the two boundaries more separate
<mjordan> the only problem I see with that is we'll have yet another loadable module that can't be unloaded
<file> we can either have it as a loadable module, or still an internal file that just registers with the core still
<mjordan> I kind of lack the latter
<mjordan> I doubt we'll be looking to hotswap DNS libraries
<file> I'm not so much looking at hot swapping - just swapping if something nicer comes along
<mjordan> true
<mjordan> You may want to think about adding a unit test enabled API only that allows us to add a test resolver
* oej has quit (Quit: Leaving.)
<mjordan> that way you can test out the threading mechanisms/callbacks from unit tests
* file nods</pre>
 </blockquote>







</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Last night, it was not immediately obvious that you meant, "this is intended to be a façade around third-party resolver implementation(s)". The way I read it was, "I intend for this API to be a thin wrapper around resolver implementations (that I intend to implement).

Perhaps it wouldn't be a bad idea to outright state this in the wiki overview section such that no one else gets confused like I apparently was. :p</pre>
<br />










<p>- Ashley</p>


<br />
<p>On February 22nd, 2015, 6:25 p.m. CST, Joshua Colp wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Joshua Colp.</div>


<p style="color: grey;"><i>Updated Feb. 22, 2015, 6:25 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">A wiki page is present at:

https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API

Which details a new DNS API for Asterisk. This exists as a thin wrapper over other resolver libraries. The core part provides a common interface and some additional features, such as NAPTR/SRV parsing and recurring lookups. Examples are provided which cover the common use cases for the API.

Some stuff to think about:

1. Does this encompass everything we think a low level API should?
2. Are there any higher level APIs that would be useful to have?
3. Is the usage intuitive and easy?
4. Are there other examples which would help?
5. Do we want resolvers to be actual modules or keep them in-core?
6. Anything else you think of

Have at it!</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I've logically run through the API and examples to ensure they provide what is needed for the future, to make them as easy as possible to use, and to ensure higher level APIs can be created.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

</ul>

<p><a href="https://reviewboard.asterisk.org/r/4437/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>