<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, 1:53 a.m. UTC, <b>Ashley Sanders</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;">These are my findings regarding the first few sections of the document. On the technical-side, I have only made one small observation. All other observations are related to phrasing or a request for more information. At this time, I am still reviewing the API and examples sections.


As a general observation, I suggest stating somewhere in this document the RFCs we are supporting with the API. I have seen other DNS server implementations do something similar on their project's home and/or wiki pages.


Overview

"The Asterisk DNS API is designed as a thin wrapper over resolver implementations." By resolver implementations, plural, do you mean the DNS server will serve as a thin wrapper around implementations of a full-service resolver and a stub resolver?

So that your intentions are clearly conveyed from the start, I suggest that both occurrences of the phrase "some dns types" (last sentence in the overview) should be replaced with the concrete dns lookup/request/record types that this implementation will support.


Threading

Perhaps consider rephrasing this section to something like:

"The API provides a guarantee that it is safe to initiate and cancel queries from any thread. It does NOT, however, provide a guarantee that the ordering of queries shall be preserved. In other words, if you execute multiple queries individually, you will not necessarily receive callbacks in the order the queries were originally executed. This API only guarantees that an individual DNS result and records are safe to retrieve within the scope of the respective asynchronous callback."

Also, I think, if we receive a 'cancel' query, that should trump any other queries currently in the queue. Imho, it wouldn't make much sense to make a user wait for the queue to empty before executing the cancel (assuming the cancel query was last in line).


Query

I think we should provide more information here about the way we intend to implement the mechanics of queries under the hood: 

>From wikipedia (http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resolvers):
"A DNS query may be either a non-recursive query or a recursive query:

A non-recursive query is one in which the DNS server provides a record for a domain for which it is authoritative itself, or it provides a partial result without querying other servers.
A recursive query is one for which the DNS server will fully answer the query (or give an error) by querying other name servers as needed. DNS servers are not required to support recursive queries."


Result
As a consumer of the API, I would want to know specifically the kind(s) of information about the DNS query contained in the result. Also, does this return an error if it is impossible to get an answer for the query?


Record - Here is where I would go into more detail the types of records we support

</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;">The RFCs depend on the resolver implementation itself. I'm also not sure about documenting record types. Resolver libraries generally don't care - they just provide the raw record back and it's up to you to interpret and parse them.  As for cancelling - there is no queue. If you cancel a query, it's cancelled then. How queries behave also depend on the resolver implementation itself (and its configuration). I'll extend the result with error information if I can.</pre>
<br />










<p>- Joshua</p>


<br />
<p>On February 23rd, 2015, 12:25 a.m. UTC, 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. 23, 2015, 12:25 a.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>