refresh_callback: zone , after bind9 upgrade

[Brad Knowles]

At 11:19 PM +0000 8/9/01, Barry Margolin wrote:

>  So they think it's better to do it twice than do it right the first time
>  (which is actually at least the second time, since BIND 1-8 could be
>  considered the first time)?

	BIND 9 was a clean rewrite from scratch, using the basic 
principles of proper nameserver design.  Therefore, there was no code 
re-use from BIND 8, nor was there much error message re-use, since I 
understand that guys like Paul Vixie and Mark Andrews (who know the 
BIND 8 code backwards and forwards) were not much involved in doing 
BIND 9.

	Making a point of going through the BIND 8 code and writing down 
every single error message and the circumstances in which that error 
message cropped up, so that this behaviour could be perfectly 
duplicated in BIND 9, was simply not an important design criteria.

>                               Do you really think that they'll find the time
>  and resources to go back through all the error messages, when there's
>  always more critical work to be done on the program?  This is the type of
>  project that typically sits at the bottom of the priority list for years.

	If you really feel this strongly about it, then I'd suggest you 
stop bitching, and start reviewing some BIND 8 code, so as to bring 
forward all your favourite error messages.  I'm sure that code 
contributions would be more than welcomed by the ISC and Nominum.

>  I don't think they should have reused the old wording.  I think that since
>  they were doing a complete rewrite, and had to compose new error messages,
>  they should have composed understandable ones.

	This is a different issue altogether, and does not relate back to 
your previous statement:

		You guys are presumably intimately familiar with most of
		BIND 8's error messages.  You could have simply reused
		the old wording in cases where they applied, but instead
		you decided to come up with new wording from scratch.

	I will agree that good error reporting is highly desirable. 
However, I also understand how much work went into a complete, 
ground-up re-write of BIND 9 based on first principles.

	When you get an entire team of people involved in doing a project 
like this, and they get into serious "hack mode", it is not at all 
unusual to find that techies naturally write error messages for other 
techies (i.e., mostly their co-workers on the team), and even if you 
ask them to spend a lot of time to try and make the wording as 
crystal clear as possible, the result is frequently still extremely 
opaque and obtuse to any outsider (including people like you and me).


	This is life.  You can either learn to deal with it, and do your 
part to help fix the situation, or not.  The choice is up to you.

>  It takes no more time or resources to compose understandable error messages
>  than to compose cryptic ones.

	Not at all true.  Composing error messages that are actually 
generally understandable is one of the most difficult tasks in 
writing a program, because you basically have to summarize into a 
single line the entire state of the massive million-line (or 
whatever) program, and express enough information to be useful 
without expressing so much information as to cause data overload.

	Getting that balance just right is one of the rarest gifts I've 
ever seen from any programmer.


	IMO, this is something that the folks at Men & Mice do really, 
really well with DNS Expert Professional -- the first DNS debugging 
tool I've ever encountered that has plain English descriptions of the 
error.

-- 
Brad Knowles, <brad.knowles at skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA