moving libaddns top-level and "merging" libcli/dns

[Andrew Bartlett]

On Fri, 2012-05-25 at 06:58 +0200, Kai Blin wrote:
> On 2012-05-23 18:47, Alexander Bokovoy wrote:
> 
> Hi Alexander,
> 
> I just noticed this patchset because it broke some of my rebases..
> 
> >        via  744f991 libcli/dns: make 'clidns' private library out of DNS code in WAF build
> 
> What is this needed for? I don't understand the reason mentioned in the
> commit message.
> 
> >     After consolidating DNS resolver code to lib/addns, there is one piece
> >     that still needs to be moved into a common DNS resolver library: DNS_HOSTS_FILE
> >     subsystem. Unfortunately, direct move would require lib/addns to depend on
> >     libcli/util/{ntstatus.h,werror.h} (provided by errors subsystem).
> >     
> >     In addition, moving libcli/dns/* code to lib/addns/ would make conflicting
> >     the dns_tkey_record struct. The conflict comes from source4/dns_server/ and is due
> >     to use of IDL to define the struct. lib/addns/ library also provides its own definition
> >     so we either need to keep them in sync (rewrite code in lib/addns/ a bit) or
> >     depend on generated IDL headers.
> 
> A while ago when I initially proposed the internal DNS implementation, I
> got quite some flak from Simo for duplicating this implementation, and
> one of the reasons I mentioned was that this would finally allow us to
> get rid of the multiple implementations of hand-marshalled DNS we
> already have in the tree. Moving libaddns top-level and then bending the
> new implementation around to make things still work is straight against
> the idea behind using the IDL-based async client library.
> 
> Also, I'd like to point out that dns_host_file is a terrible, terrible
> hack and is not supposed to go into the LIBCLI_DNS library at all.

I fully agree.  As soon as we can get the internal DNS server up and
going in make test, I want to see dns_host_file go away, and stay
away :-)

> >     Thus, making a private library and subsystem clidns is an intermediate step
> >     that allows to buy some time fore refactoring.
> 
> Can you please, please discuss refactoring of code that is pretty recent
> with the person who wrote the code in the first place? Already now this
> patch forces me to clean up both my work-in-progress code as well as the
> already committed code to move that dns_host_file hack out of the client
> library.
> 
> I also think that we really, really should try to get rid of libaddns,
> and not mark it as "ok to be used project-wide" by moving it to the top
> level.

One question on libaddns:

In the autoconf build, this is published as a public library.  Now I'm a
bit confused as to why: is Samba really upstream for a public DNS
library?

Once we agree that libaddns is not a public library that we public,
depending on IDL headers should not be an issue, nor should it be an
issue to simply ditch it entirely.   (As a library, it really doesn't
feel like Samba code, and we are only now just getting rid of stupid
ideas like using libuuid just to generate a random GUID string). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org