BIND - sorting of reverse domain.

[Danny Mayer]

At 03:57 AM 7/9/02, D. Stussy wrote:
>  Furthermore, the RFC requires an order
>for the MEMORY IMAGE, but again, that isn't relevent to the FILE image I 
>queried
>about.

RFC's don't care about memory image.  Making such a statement shows that
you didn't bother to actually read them.  Memory Image is an implementation
detail rightly left to the implementors.

>Since others said that a zone ISN'T stored in alphabetical/machine order, 
>but is
>written out as such, I properly concluded that before writing, an additional
>sort of the zone names was occuring so as to make the file listing of the zone
>appear in a human readable pattern.  It wasn't until later that they finally
>admitted that it was a side-effect of their tree-traversal (which
>coincidentally, did traverse the tree in machine order to write the file) -
>which means that it IS in fact sorted in machine order to begin 
>with.  Beyond my
>query, my assertions were as a result of their false statements.

Noone made any false statements to you.  You just didn't understand the
answers when given.


>My follow-up question, once I overcame their falsehoods, then was:  Why was it
>chosen to save the file in machine order when that requires a tree-rebalance
>performance penalty when reading it back in (upon restart)?  If it is saved in
>this other tree traversal order, the rebalance penalty is completely 
>avoided (as
>long as the zone file hadn't been tampered with in the meantime).  I still 
>await
>an answer to that one.

Noone really cares. The file is written the way it is due to the way the 
tree is
traversed. The file when read back in is read record by record and each one is
added to the tree in the appropriate place. What's the real issue?

Danny