<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2 jun 2014, at 21:05, Dick Franks <<a href="mailto:rwfranks@acm.org">rwfranks@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Your claim was that axfr() API had changed, which it has not.<br><br></div></div></div></div></blockquote><div><br></div><div>I meant the AXFR operation, not the exact axfr() method.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Change was clearly anticipated by somebody because the perldoc for 0.74 also contains a warning:</div><div><br>IMPORTANT:<br><br> This method currently returns the "IO::Socket::INET" object that will be<br>
used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()"<br> returning a socket object. THIS MIGHT CHANGE in future releases.<br><br></div><div>And it just did.<br><br></div></div></div></div></blockquote><div><br></div><div>That warning has been there for a very long time. Because of it I have always made sure not to use the return value from axfr_start() for anything other than true/false determination. Changing what axfr_start() returns is perfectly in accordance with long-standing documentation, and I have no issue with doing so. I do have an issue with removing the method from the documented public API.</div><div><br></div><div>The warning does _not_ say that axfr_next() is similarly afflicted. The warning is specifically about what axfr_start() returns. Changing what axfr_next() returns is a change in the documented public API (as is removing it, obviously).</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="word-wrap:break-word"><div><br></div><div>If memory usage is your main objection, it would be sensible to know how big a problem that poses.<br>
<br></div></div></div></div></div></blockquote><div><br></div><div>Well, the memory use is what makes Net::DNS versions 0.75 and 0.76 completely unusable for one of .SE’s current applications. It could in theory still work if moved to a server with much more RAM, but I hope you can understand that the argument “We need to buy a new big server because Net::DNS changed their API” is not going to work very well.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="word-wrap:break-word"><div></div><div>Upper bound memory useage estimate: 1350 . 6M6 = 8.9G bytes.</div></div></div></div></div></blockquote><div><br></div><div>Devel::Size gives me about 3200 bytes for a Net::DNS::RR::RRSIG, so I think you estimate is low by at least half. Perl was not designed to be memory-efficient...</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="word-wrap:break-word"><div>Using axfr_start() and axfr_next() to get the packets and iterating over the RRs inside would seem to be the better option.</div></div></div></div></div></blockquote></div><div><br></div>In Net::LDNS, we have a method that takes a code reference as its argument and runs that code once for every RR in the AXFR, with the RR object as its only argument. That way the method can keep as much state as it likes, and the amount of memory needed is unaffected by the number of records received. I find the interface clean and convenient to work with, but then I came up with it so I’m obviously biased in its favor.<div><div><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="font-size: 12px; "><div><br class="Apple-interchange-newline">-- </div><div>Calle Dybedahl</div><div><a href="mailto:calle@init.se">calle@init.se</a> -*- +46 703 - 970 612</div><div><br></div></span></span><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>