[bind10-dev] DNS message API: resource data classes

[Francis Dupont]

> (if we use a dedicated "RDATA" namespace, we might simply use the type
> name as the C++ class name:
>         namespace RDATA {
>             namespace IN {
>                 class A : public Rdata {
> 			...
> 		};
>                 class AAAA : public Rdata {
> 			...
> 		};
> 	    }
> 	}
> )

=> it is the dnspython style and seems fine.

> Another obvious candidate is to use inheritance:
> 
>         class INRdata : public Rdata {};
>         class ARdata : public INRdata {};
> 
> but this is probably not the best approach because the same type could
> belong to different classes (so we need to address name conflict
> anyway).

=> it is not a good idea: to exist for a class has nothing to do
with inheritance...

> >  - I can't see a virtual fromText(), I believe the idea is to
> >   provide it in constructors of subclasses and with an external
> >   factory function, isn't it?
> 
> I don't understand the question.  Could you be more explicit?

=> I came back to this with more details in another message.

> >  - there is no comparaison virtual function. I have no problem
> >   with limiting comparaison between Rdatas inside the same
> >   subclass (i.e., rdatatype and rdataclass must be the same) even
> >   we need full comparaison (i.e., not only == and !=).
> >   Note DNSSEC requires a more generic comparaison between rdatasets.
> 
> I thought about it, and was not sure if we'd need it or how to realize
> that.  But we'll probably need it to handle a set (or list or some
> container) of Rdatas in polymorphic way, even though all the RDATAs
> are assumed to be of the same class and type.

=> for DNSSEC we need to be able to sort RDATAs of same class and type,
to sort RRSETs of same owner, and to sort Names.

> >  - why _rdclass and _rdtype are not defined in Rdata class itself
> >   (i.e., Rdata class has not to be fully abstract).
> 
> Because the type can be determined by the class type itself in most
> cases.  We could still keep _rdtype, but it would be redundant
> information in such cases and may cause a trouble in ensuring
> consistency.

=> I see...

> >  - there are a lot of cases we'd like to see a XXRdata to be
> >   a WireRdata too, and the opposite. So the separate class is
> >   perhaps a bad idea, I imagine more a cache in the Rdata class itself.
> 
> That (combine wire/non-wire in a single class) is certainly an
> option.  I actually considered that path, but chose to separate them
> in this version of proposal to keep XXRdata as small as possible.
> When we parse a response and construct a set of RDATA from wire, we
> probably want to handle the data as opaque information whenever
> possible, and want to avoid the overhead of instantiating specific
> XXRdata classes.

=> I believed this but I am afraid it is *required* to validate the
wire format when it is possible. So we can't deal with a known class/type
as an opaque bunch of bits.

> But I agree this is worth revisiting.

=> I'd like to get other opinions about this validation requirement.

> >  - IMHO RdataSet could be sorted. If it is always kept sorted some
> >   operations are easier but this has a cost of all others. Perhaps
> >   we simply need a flag to keep the sorted/unsorted state.
> 
> Good point.  I wondered this issue, too (btw you mean sorting RDATA of
> an RdataSet, right?).  If we want to support "rrset-order fixed", I
> think we should keep the "given ordering" (and support the ability to
> sort them separately) anyway.  Otherwise, we might simply keep them as
> an STL set (then we can automatically keep them sorted, and don't have
> to worry about duplicate RDATA).

=> in fact I have a mixed opinion about this: on one hand it is fine
to use ordered data structures but on other hand I am afraid the result
would be an artificial constraint, for instance on a cache server
if we order "en passant" responses.

Francis_Dupont at isc.org