> On Feb. 26, 2015, 1:53 a.m., Ashley Sanders wrote: > > 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 > > > >
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. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/#review14556 ----------------------------------------------------------- On Feb. 23, 2015, 12:25 a.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4437/ > ----------------------------------------------------------- > > (Updated Feb. 23, 2015, 12:25 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > 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! > > > Diffs > ----- > > > Diff: https://reviewboard.asterisk.org/r/4437/diff/ > > > Testing > ------- > > 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. > > > Thanks, > > Joshua Colp > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
