Users Want *Seamless* Solutions, Not Patchwork (was Re: Users want solutions, not buzzwords)

[Danny Mayer]

Kevin Darcy wrote:

> My point is, though, whether it's 3Kb or 3Mb, waste is waste. Because of
> your design decision to split the AXFR server from the main authoritative
> server, you have to put lookup code into axfrdns so that people can run
> axfrdns alongside tinydns on the same address. This lookup code in axfrdns
> duplicates what's already in tinydns. Now, maybe if you had a way to put
> the code which was shared by the two programs into a shared object,
> dynamically-linked from both tinydns and axfrdns, I wouldn't be griping so
> much. But that would complicate the build and installation process,
> wouldn't it? Overall, I don't think it would be a net win in terms of
> ease-of-use. You're in a no-win situation because of your fundamental
> design decision. rsync and ssh are nifty tools for replicating files, but
> in the process of accommodating (nay promoting) their use, apparently you
> have sacrificed some elegance/efficiences that you could have otherwise
> realized, for folks who want to use plain old AXFR for replicating their
> zone data -- they have to configure and run a separate program, which
> partially duplicates tinydns code. Your personal bias against AXFR is
> reflected in the design of your package. What a shame for folks who find
> AXFR quite usable, or might actually prefer it (gasp!). Apparently they
> don't matter....

You have to remember that DJB describes djbdns as a research project.
A research project doesn't have to satisfy anyone else's requirements,
just the goals of the research.

>
> > The documentation also answers your remaining questions. RTFM.
>
> I have RTFM'ed, but the FM hasn't been of any help.
>
>
> One would have to grovel through the code to get the answers to these
> questions. I decline to do so. Such laborious methods of ascertaining
> answers to basic configuration questions should not be necessary with a
> package which makes extravagant claims about its "ease of use".
>
> (To everyone: yes, I know this thread is now starting to drift from
> strictly "ease of use" issues to quality-of-documentation issues, but my
> opinion is that inadequacy of documentation is a factor in "ease of use",
> since it's hard to configure a DNS package if you can't easily find out
> *how* to configure it. Besides, Dan started the drift by telling me to
> RTFM... :-)

    Research projects don't require documentation to satisfy all questions,
just
the ones that the research was designed to answer.  That's the point of
research after all.

        Danny