[bind10-dev] [Fwd: Re: DNS message API: the message class]

[Jelte Jansen]

woops, i only sent this to jinmei instead of to the complete list

-------- Original Message --------
Subject: Re: [bind10-dev] DNS message API: the message class
Date: Thu, 08 Oct 2009 12:43:36 +0200
From: Jelte Jansen <jelte at isc.org>
To: JINMEI Tatuya / 神明達哉 <jinmei at isc.org>
References: <m2y6nvplpp.wl%jinmei at isc.org>	 <4ACC889B.5000202 at isc.org> 
<m24oqaiazz.wl%jinmei at isc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JINMEI Tatuya / 神明達哉 wrote:
> 
> Note: even though the current prototype version adopts the
> RRset-centric approach, I'm not intending to consider it a fixed
> decision.  I'm certainly biased in the design comparison (because I'm
> so familiarized with the BIND9 implementation), so I'm happy to hear
> other opinions.
> 

Unbound also uses the RRset-centric approach (it calls it a packed_rrset). In
fact, I was planning to do the same on the next big version of ldns, only in
addition to the basic RR type (not instead of).

I don't dissaprove of this approach, it's mostly the naming that got me confused
:) Although if we can fit in direct RR handling as well in an easy way it would
be nice for some use-cases of the library for other projects.

>> Am i correct in assuming that we will be writing (possibly static)
>> functions for the specific rdata fields (like an int32 rdata field,
>> or a domainname rdata field), which will then be reused by all Rdata
>> classes that need them?
> 
> I'd first like to note that this is a common question whether we use
> "Rdata" or "RR".
> 

Well, the thing is (this probably finds its root in naming again, and me
deriving things from the way ldns named them), is that these are two different
levels; for instance, there's the TXT Rdata field, which is a string, and the
TXT RR, which contains an arbitrary length list of TXT Rdata fields.

Conversion rules (to/from wire/string/etc), are specific per rdata field type,
and shared between RRs; My point was that we don't need to rewrite the function
to convert a TXT field for every RR type that contains one or more text fields,
regardless of the external API (except insofar that these might or might not
actually *be* in the external API)

I agree with this approach:

> Second, this is actually an open issue.  I'd personally prefer
> providing per RR-type accessors, that is,
> 
> - if rdata is an instance of "A Rdata" class, rdata.get_address()
>   returns an IPv4 address.
> - if rdata is an instance of "AAAA Rdata" class, rdata.get_address()
>   returns an IPv6 address.
> - if rdata is an instance of "NS Rdata" class, rdata.get_nsname()
>   returns (probably a reference to) an instance of DNS name, which
>   represents the name server's name.
> - if rdata is an instance of "SOA Rdata" class, rdata.get_serial()
>   returns a 32-bit integer representing the SOA's serial number.

except that serial might need to be another type to easily do serial arithmetic :)

> We have a common "get_uint32()" member function for all subclasses of
> "Rdata", and if (e.g.) rdata is an instance of "SOA Rdata" class and
> we want to get its "serial" field, we'd do:
> 
>   rdata.get_uint32(3); // returning the 3rd field of the rdata as 32bit int
>   (get_uint32() is redefined in the SOA Rdata class so that it can
>   identify the position of the specified field)
> 
> Am I understanding you correctly?  If so, this would be more scalable
> than the first approach.  But, IMO, this is not a user/programmer
> friendly in that the user needs to know more details of the rdata
> format.
> 

i'm not sure whether this actually is more scalable, it does make the full API
smaller, but that's just symbols :) it certainly is harder to use.

> BIND9/dnspython/dnsruby/Net::DNS all adopt the first approach; ldns
> takes the second approach.  Considering pros and cons of both ways,
> I'm currently preferring the first way, but I'm open to other
> suggestions.
> 

Actually, ldns takes both; the second approach is the basic one, but there is a
slew of convenience functions that give the API users the first one. Only in a
non-OO way obviously.

>> Still, RdataClass and RdataType could be named better imo
>>
>> - - personal opinion, ignore; our naming convenctions make the Rdata class names
>> ugly (ARdata, AAAARdata) :p
> 
> Naming things is one of many fields where I'm not good:-)  If you have
> specific suggestions I'm happy to hear that.  In particular I don't
> like xxxRdata either.  Regarding this one, since we should
> differentiate class-specific types in some way, we might use
> namespaces as part of class name:
> 
> class ISC::DNS::RDATA::IN::A;
> class ISC::DNS::RDATA::CH::A;
> class ISC::DNS::RDATA::IN::AAAA;
> class ISC::DNS::RDATA::ANY::NS;
> class ISC::DNS::RDATA::ANY::DNSKEY;
> etc.
> 
> Are these better?  (An obvious downside is these look lengthy)
> 

I like this better, part of the name length here is the still open discussion
about the general namespace, although still only a small part in this case,
since both ISC and DNS are short acronyns :)

My personal feeling is that RRDATA instead of RDATA would convey the contents
better, in this approach, since we're talking about all the data of the rrs. But
loud screaming of 'for the love of <my deity>, NO', or other suggestions are welcome

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrNwlgACgkQ4nZCKsdOncXh5QCeIluU8M/DCE/EeLKZsgZgoqTH
+SUAoNlrPSTH00SPBCaeXMsArpaXBl7G
=/T53
-----END PGP SIGNATURE-----