--- AnyEvent-SNMP/SNMP.pm	2010/10/31 18:26:27	1.11
+++ AnyEvent-SNMP/SNMP.pm	2014/11/24 18:16:54	1.13
@@ -34,14 +34,14 @@
 and memory usage. Most AnyEvent backends (including the pure-perl backend)
 fare much better than the Net::SNMP dispatcher.
 
-Another major added fetaure of this module over Net::SNMP is automatic
+Another major added feature of this module over Net::SNMP is automatic
 rate-adjustments:  Net::SNMP is so slow that firing a few thousand
 requests can cause many timeouts simply because Net::SNMP cannot process
 the replies in time. This module automatically adapts the send rate to
 avoid false timeouts caused by slow reply processing.
 
 A potential disadvantage of this module is that replacing the dispatcher
-is not at all a documented thing to do, so future changes in Net::SNP
+is not at all a documented thing to do, so future changes in Net::SNMP
 might break this module (or the many similar ones).
 
 This module does not export anything and does not require you to do
@@ -71,7 +71,7 @@
 
 To avoid this, you can (and should) limit the number of outstanding
 requests to a number low enough so that parsing time doesn't introduce
-noticable delays.
+noticeable delays.
 
 Unfortunately, this number depends not only on processing speed and load
 of the machine running Net::SNMP, but also on the network latency and the
@@ -82,7 +82,7 @@
 
 Increasing C<$MAX_OUTSTANDING> will not automatically use the
 extra request slots. To increase C<$MAX_OUTSTANDING> and make
-C<AnyEvent::SNMP> make use of the extra paralellity, call
+C<AnyEvent::SNMP> make use of the extra parallelity, call
 C<AnyEvent::SNMP::set_max_outstanding> with the new value, e.g.:
 
    AnyEvent::SNMP::set_max_outstanding 500;
@@ -105,10 +105,10 @@
 it increases $MAX_OUTSTANDING.
 
 This has the result of adjusting the number of outstanding requests so that
-the recv queue is between the minimum and maximu, usually.
+the recv queue is between the minimum and maximum, usually.
 
 This algorithm works reasonably well as long as the responses, response
-latencies and processing times are the same size per packet on average.
+latencies and processing times are the same per packet on average.
 
 =back
 
@@ -143,6 +143,10 @@
 # Net::SNMP::Dispatcher, but much more awkward.
 use Net::SNMP::Dispatcher;
 
+# we could inherit fro Net:SNMP::Dispatcher, but since this is undocumented,
+# I'd rather see it die (and reported) than silenty and subtly fail.
+*msg_handle_alloc = \&Net::SNMP::Dispatcher::msg_handle_alloc;
+
 sub Net::SNMP::Dispatcher::instance {
    AnyEvent::SNMP::
 }
@@ -150,7 +154,7 @@
 use Net::SNMP ();
 use AnyEvent ();
 
-our $VERSION = '1.0';
+our $VERSION = '6.0';
 
 $Net::SNMP::DISPATCHER = instance Net::SNMP::Dispatcher;
 
@@ -339,7 +343,7 @@
    1
 }
 
-sub activate($) {
+sub loop($) {
    while ($BUSY) {
       $DONE = AE::cv;
       $DONE->recv;
@@ -347,6 +351,9 @@
    }
 }
 
+*activate = \&loop; # 5.x compatibility?
+*listen   = \&loop; # 5.x compatibility?
+
 sub one_event($) {
    # should not ever be used
    AnyEvent->one_event; #d# todo
@@ -357,6 +364,15 @@
    kick_job;
 }
 
+# not provided yet:
+# schedule            # apparently only used by Net::SNMP::Dispatcher itself
+# register            # apparently only used by Net::SNMP::Dispatcher itself
+# deregister          # apparently only used by Net::SNMP::Dispatcher itself
+# cancel              # apparently only used by Net::SNMP::Dispatcher itself
+# return_response_pdu # apparently not used at all?
+# error               # only used by Net::SNMP::Dispatcher itself?
+# debug               # only used by Net::SNMP::Dispatcher itself?
+
 =head1 SEE ALSO
 
 L<AnyEvent>, L<Net::SNMP>, L<Net::SNMP::XS>, L<Net::SNMP::EV>.