AnyEvent
view release on metacpan or search on metacpan
- document AnyEvent::Impl::IOAsync::set_loop and
$AnyEvent::Impl::IOAsync::LOOP. Though only documented now, this
functionality has _always_ been available.
- force a toplevel domain name in t/81_hosts.t (analyzed by
David Jack Wange Olrik).
- document that AnyEvent::Log uses AnyEvent::IO.
- warn about AnyEvent::Filesys::Notify performance.
- praise the joys of AnyEvent::Fork::*.
- time for an =encoding directive.
- do no longer use JSON to create a default json coder, use
JSON::XS or JSON::PP directly.
7.05 Wed Aug 21 10:38:08 CEST 2013
- uts46data.pl couldn't be found due to wrong naming of the file
(reported by Fulko Hew).
- handle lone \015's properly in AE::Handle's default line read
(reported by various people).
- untaint ip addresses found in /etc/hosts (patch by José Micó).
- the memleak fix in 7.03 caused resolving via /etc/hosts to always
fail on first use (reported and testcase by Andrew Whatson).
- expose AnyEvent::Log::format_time, and allow users to redefine it.
- load AnyEvent::Handle only on demand in AnyEvent::DNS,
so AnyEvent::Socket users have smaller memory footprint
in the common case.
- add AnyEvent::Handle->push_shutdown method.
- add an additional error message parameter to AnyEvent::Handle's
on_error callback (for TLS, $! is still available).
- add AnyEvent::Handle on_starttls/on_stoptls callbacks.
- make AnyEvent::Handle more robust against early connection
failures (during new), and return C<undef> in that case
from the constructor.
- AnyEvent::Handle will now try to load only JSON::XS first,
then fall back to JSON.
- format_ipv4/format_ipv6 are now exported by default, for symmetry,
and because it was documented that way.
4.451 Fri Jul 3 00:28:58 CEST 2009
- do not clear rbuf when shutting down an AnyEvent::Handle
object - doing so breaks AnyEvent::HTTP.
4.45 Mon Jun 29 22:59:26 CEST 2009
- a write error could cause AnyEvent::Handle to create
"Canary::Stability" : "0",
"ExtUtils::MakeMaker" : "6.52"
}
},
"runtime" : {
"recommends" : {
"Async::Interrupt" : "1",
"EV" : "4",
"Guard" : "1.02",
"JSON" : "2.09",
"JSON::XS" : "2.2",
"Net::SSLeay" : "1.33",
"Task::Weaken" : "0"
}
}
},
"release_status" : "stable",
"version" : 7.17
}
name: AnyEvent
no_index:
directory:
- t
- inc
recommends:
Async::Interrupt: '1'
EV: '4'
Guard: '1.02'
JSON: '2.09'
JSON::XS: '2.2'
Net::SSLeay: '1.33'
Task::Weaken: '0'
version: 7.17
Makefile.PL view on Meta::CPAN
PMLIBDIRS => ["lib"],
# PREREQ_PM => {
# Task::Weaken => 0,
# },
CONFIGURE_REQUIRES => { "ExtUtils::MakeMaker" => 6.52, "Canary::Stability" => 0 },
META_MERGE => {
recommends => {
"Task::Weaken" => 0,
"Net::SSLeay" => 1.33,
"JSON" => 2.09,
"JSON::XS" => 2.2,
"EV" => 4.00,
"Guard" => 1.02,
"Async::Interrupt" => 1.0,
}
},
PM => {
'lib/AE.pm' => '$(INST_LIB)/AE.pm',
'lib/AnyEvent.pm' => '$(INST_LIB)/AnyEvent.pm',
'lib/AnyEvent/DNS.pm' => '$(INST_LIB)/AnyEvent/DNS.pm',
'lib/AnyEvent/Debug.pm' => '$(INST_LIB)/AnyEvent/Debug.pm',
If you only use backends that rely on another event loop (e.g.
"Tk"), then this module will do nothing for you.
Guard
The guard module, when used, will be used to implement
"AnyEvent::Util::guard". This speeds up guards considerably (and
uses a lot less memory), but otherwise doesn't affect guard
operation much. It is purely used for performance.
JSON and JSON::XS
One of these modules is required when you want to read or write JSON
data via AnyEvent::Handle. JSON is also written in pure-perl, but
can take advantage of the ultra-high-speed JSON::XS module when it
is installed.
Net::SSLeay
Implementing TLS/SSL in Perl is certainly interesting, but not very
worthwhile: If this module is installed, then AnyEvent::Handle (with
the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
Time::HiRes
This module is part of perl since release 5.008. It will be used
when the chosen event library does not come with a timing source of
lib/AnyEvent.pm view on Meta::CPAN
If you only use backends that rely on another event loop (e.g. C<Tk>),
then this module will do nothing for you.
=item L<Guard>
The guard module, when used, will be used to implement
C<AnyEvent::Util::guard>. This speeds up guards considerably (and uses a
lot less memory), but otherwise doesn't affect guard operation much. It is
purely used for performance.
=item L<JSON> and L<JSON::XS>
One of these modules is required when you want to read or write JSON data
via L<AnyEvent::Handle>. L<JSON> is also written in pure-perl, but can take
advantage of the ultra-high-speed L<JSON::XS> module when it is installed.
=item L<Net::SSLeay>
Implementing TLS/SSL in Perl is certainly interesting, but not very
worthwhile: If this module is installed, then L<AnyEvent::Handle> (with
the help of L<AnyEvent::TLS>), gains the ability to do TLS/SSL.
=item L<Time::HiRes>
This module is part of perl since release 5.008. It will be used when the
lib/AnyEvent/Handle.pm view on Meta::CPAN
set, then it will be invoked after freeing the TLS session. If it is not,
then a TLS shutdown condition will be treated like a normal EOF condition
on the handle.
The session in C<< $handle->{tls} >> can still be examined in this
callback.
This callback will only be called on TLS shutdowns, not when the
underlying handle signals EOF.
=item json => L<JSON>, L<JSON::PP> or L<JSON::XS> object
This is the json coder object used by the C<json> read and write types.
If you don't supply it, then AnyEvent::Handle will create and use a
suitable one (on demand), which will write and expect UTF-8 encoded
JSON texts (either using L<JSON::XS> or L<JSON>). The written texts are
guaranteed not to contain any newline character.
For security reasons, this encoder will likely I<not> handle numbers and
strings, only arrays and objects/hashes. The reason is that originally
JSON was self-delimited, but Dougles Crockford thought it was a splendid
idea to redefine JSON incompatibly, so this is no longer true.
For protocols that used back-to-back JSON texts, this might lead to
run-ins, where two or more JSON texts will be interpreted as one JSON
text.
For this reason, if the default encoder uses L<JSON::XS>, it will default
to not allowing anything but arrays and objects/hashes, at least for the
forseeable future (it will change at some point). This might or might not
be true for the L<JSON> module, so this might cause a security issue.
If you depend on either behaviour, you should create your own json object
and pass it in explicitly.
=item cbor => L<CBOR::XS> object
This is the cbor coder object used by the C<cbor> read and write types.
lib/AnyEvent/Handle.pm view on Meta::CPAN
$handle->push_write (cbor => ["method", "arg1", "arg2"]); # whatever
An AnyEvent::Handle receiver would simply use the C<cbor> read type:
$handle->push_read (cbor => sub { my $array = $_[1]; ... });
=cut
sub json_coder() {
eval { require JSON::XS; JSON::XS->new->utf8 }
|| do { require JSON::PP; JSON::PP->new->utf8 }
}
register_write_type json => sub {
my ($self, $ref) = @_;
($self->{json} ||= json_coder)
->encode ($ref)
};
lib/AnyEvent/Handle.pm view on Meta::CPAN
1
}
};
=item json => $cb->($handle, $hash_or_arrayref)
Reads a JSON object or array, decodes it and passes it to the
callback. When a parse error occurs, an C<EBADMSG> error will be raised.
If a C<json> object was passed to the constructor, then that will be
used for the final decode, otherwise it will create a L<JSON::XS> or
L<JSON::PP> coder object expecting UTF-8.
This read type uses the incremental parser available with JSON version
2.09 (and JSON::XS version 2.2) and above.
Since JSON texts are fully self-delimiting, the C<json> read and write
types are an ideal simple RPC protocol: just exchange JSON datagrams. See
the C<json> write type description, above, for an actual example.
=cut
register_read_type json => sub {
my ($self, $cb) = @_;
( run in 0.354 second using v1.01-cache-2.11-cpan-05444aca049 )