POE::Component::IRC - a fully event-driven IRC client module.
# A simple Rot13 'encryption' bot
use strict; use warnings; use POE qw(Component::IRC);
my $nickname = 'Flibble' . $$; my $ircname = 'Flibble the Sailor Bot'; my $server = 'irc.blahblahblah.irc';
my @channels = ('#Blah', '#Foo', '#Bar');
# We create a new PoCo-IRC object my $irc = POE::Component::IRC->spawn( nick => $nickname, ircname => $ircname, server => $server, ) or die "Oh noooo! $!";
POE::Session->create( package_states => [ main => [ qw(_default _start irc_001 irc_public) ], ], heap => { irc => $irc }, );
$poe_kernel->run();
sub _start { my $heap = $_[HEAP];
# retrieve our component's object from the heap where we stashed it
my $irc = $heap->{irc};
$irc->yield( register => 'all' );
$irc->yield( connect => { } );
return;
}
sub irc_001 { my $sender = $_[SENDER];
# Since this is an irc_* event, we can get the component's object by
# accessing the heap of the sender. Then we register and connect to the
# specified server.
my $irc = $sender->get_heap();
print "Connected to ", $irc->server_name(), "\n";
# we join our channels
$irc->yield( join => $_ ) for @channels;
return;
}
sub irc_public { my ($sender, $who, $where, $what) = @_[SENDER, ARG0 .. ARG2]; my $nick = ( split /!/, $who )[0]; my $channel = $where->[0];
if ( my ($rot13) = $what =~ /^rot13 (.+)/ ) {
$rot13 =~ tr[a-zA-Z][n-za-mN-ZA-M];
$irc->yield( privmsg => $channel => "$nick: $rot13" );
}
return;
}
# We registered for all events, this will produce some debug info. sub _default { my ($event, $args) = @_[ARG0 .. $#_]; my @output = ( "$event: " );
for my $arg (@$args) {
if ( ref $arg eq 'ARRAY' ) {
push( @output, '[' . join(' ,', @$arg ) . ']' );
}
else {
push ( @output, "'$arg'" );
}
}
print join ' ', @output, "\n";
return 0;
}
POE::Component::IRC is a POE component (who'd have guessed?) which acts as an easily controllable IRC client for your other POE components and sessions. You create an IRC component and tell it what events your session cares about and where to connect to, and it sends back interesting IRC events when they happen. You make the client do things by sending it events. That's all there is to it. Cool, no?
[Note that using this module requires some familiarity with the details of the IRC protocol. I'd advise you to read up on the gory details of RFC 1459 (http://www.faqs.org/rfcs/rfc1459.html) before you get started. Keep the list of server numeric codes handy while you program. Needless to say, you'll also need a good working knowledge of POE, or this document will be of very little use to you.]
The POE::Component::IRC distribution has a docs/ folder with a collection of salient documentation including the pertinent RFCs.
POE::Component::IRC consists of a POE::Session that manages the IRC connection and dispatches 'irc_' prefixed events to interested sessions and an object that can be used to access additional information using methods.
Sessions register their interest in receiving 'irc_' events by sending
register to the component. One would usually do this in your _start
handler. Your session will continue to receive events until you unregister.
The component will continue to stay around until you tell it not to with
shutdown.
The SYNOPSIS demonstrates a fairly basic bot.
See POE::Component::IRC::Cookbook for more examples.
Included with POE::Component::IRC are a number of useful subclasses. As they are subclasses they support all the methods, etc. documented here and have additional methods and quirks which are documented separately:
POE::Component::IRC::State provides all the functionality of POE::Component::IRC but also tracks IRC state entities such as nicks and channels.
POE::Component::IRC::Qnet is POE::Component::IRC tweaked for use on Quakenet IRC network.
POE::Component::IRC::Qnet::State is a tweaked version of POE::Component::IRC::State for use on the Quakenet IRC network.
As of 3.7, PoCo-IRC sports a plugin system. The documentation for it can be read by looking at POE::Component::IRC::Plugin. That is not a subclass, just a placeholder for documentation!
A number of useful plugins have made their way into the core distribution:
Keeps you on your favorite channels throughout reconnects and even kicks.
Glues an irc bot to an IRC network, i.e. deals with maintaining ircd connections.
Under normal circumstances irc bots do not normal the msgs and public msgs that they generate themselves. This plugin enables you to handle those events.
Generates irc_bot_addressed / irc_bot_mentioned / irc_bot_mentioned_action
events whenever your bot's name comes up in channel discussion.
Provides an easy way to handle commands issued to your bot.
See inside the component. See what events are being sent. Generate irc commands manually. A TCP based console.
Follow the tail of an ever-growing file.
Log public and private messages to disk.
Identify with FreeNode's NickServ when needed.
A lightweight IRC proxy/bouncer.
Automagically generates replies to ctcp version, time and userinfo queries.
An experimental Plugin Manager plugin.
Automagically deals with your nickname being in use and reclaiming it.
Cycles (parts and rejoins) channels if they become empty and opless, in order to gain ops.
Both CONSTRUCTORS return an object. The object is also available within 'irc_'
event handlers by using
$_[SENDER]->get_heap(). See also register and irc_registered.
spawn
Takes a number of arguments, all of which are optional:
'alias', a name (kernel alias) that this instance will be known by;
'options', a hashref containing POE::Session options;
'Server', the server name;
'Port', the remote port number;
'Password', an optional password for restricted servers;
'Nick', your client's IRC nickname;
'Username', your client's username;
'Ircname', some cute comment or something.
'UseSSL', set to some true value if you want to connect using SSL.
'Raw', set to some true value to enable the component to send irc_raw events.
'LocalAddr', which local IP address on a multihomed box to connect as;
'LocalPort', the local TCP port to open your socket on;
'NoDNS', set this to 1 to disable DNS lookups using PoCo-Client-DNS. (See note below).
'Flood', set this to 1 to get quickly disconnected and klined from an ircd >;]
'Proxy', IP address or server name of a proxy server to use.
'ProxyPort', which tcp port on the proxy to connect to.
'NATAddr', what other clients see as your IP address.
'DCCPorts', an arrayref containing tcp ports that can be used for DCC sends.
'Resolver', provide a POE::Component::Client::DNS object for the component to use.
'msg_length', the maximum length of IRC messages, in bytes. Default is 450. The IRC component shortens all messages longer than this value minus the length of your current nickname. IRC only allows raw protocol lines messages that are 512 bytes or shorter, including the trailing "\r\n". This is most relevant to long PRIVMSGs. The IRC component can't be sure how long your user@host mask will be every time you send a message, considering that most networks mangle the 'user' part and some even replace the whole string (think FreeNode cloaks). If you have an unusually long user@host mask you might want to decrease this value if you're prone to sending long messages. Conversely, if you have an unusually short one, you can increase this value if you want to be able to send as long a message as possible. Be careful though, increase it too much and the IRC server might disconnect you with a "Request too long" message.
'plugin_debug', set to some true value to print plugin debug info, default 0.
'socks_proxy', specify a SOCKS4/SOCKS4a proxy to use.
'socks_port', the SOCKS port to use, defaults to 1080 if not specified.
'socks_id', specify a SOCKS user_id. Default is none.
'useipv6', enable the use of IPv6 for connections.
spawn will supply reasonable defaults for any of these attributes which are
missing, so don't feel obliged to write them all out.
All the above options may be supplied to connect input event as well.
If the component finds that POE::Component::Client::DNS
is installed it will use that to resolve the server name passed. Disable this
behaviour if you like, by passing: NoDNS = 1>.
Additionally there is a "Flood" parameter. When true, it disables the component's flood protection algorithms, allowing it to send messages to an IRC server at full speed. Disconnects and k-lines are some common side effects of flooding IRC servers, so care should be used when enabling this option.
Two new attributes are "Proxy" and "ProxyPort" for sending your
IRC traffic through a proxy server. "Proxy"'s value should be the IP
address or server name of the proxy. "ProxyPort"'s value should be the
port on the proxy to connect to. connect will default to using the
actual IRC server's port if you provide a proxy but omit the proxy's
port. These are for HTTP Proxies. See 'socks_proxy' for SOCKS4 and SOCKS4a
support.
For those people who run bots behind firewalls and/or Network Address
Translation there are two additional attributes for DCC. "DCCPorts", is an
arrayref of ports to use when initiating DCC, using dcc(). "NATAddr", is the
NAT'ed IP address that your bot is hidden behind, this is sent whenever you
do DCC.
SSL support requires POE::Component::SSLify, as well as an IRC server that supports SSL connections. If you're missing POE::Component::SSLify, specifing 'UseSSL' will do nothing. The default is to not try to use SSL.
Setting 'Raw' to true, will enable the component to send irc_raw events to
interested plugins and sessions. See below for more details on what a irc_raw
events is :)
'NoDNS' has different results depending on whether it is set with spawn() or
connect. Setting it with spawn(), disables the creation of the
POE::Component::Client::DNS completely. Setting it with connect on the
other hand allows the PoCo-Client-DNS session to be spawned, but will disable
any dns lookups using it.
'Resolver', requires a POE::Component::Client::DNS object. Useful when spawning multiple poco-irc sessions, saves the overhead of multiple dns sessions.
'plugin_debug', setting to true enables plugin debug info. Plugins are processed inside an eval, so debugging them can be hard. This should help with that.
SOCKS4 proxy support is provided by 'socks_proxy', 'socks_port' and 'socks_id' parameters. If something goes wrong with the SOCKS connection you should get a warning on STDERR. This is fairly experimental currently.
IPv6 support is available for connecting to IPv6 enabled ircds (it won't work for DCC though). To enable it, specify 'useipv6'. Socket6 is required to be installed. If you have Socket6 and POE::Component::Client::DNS installed and specify a hostname that resolves to an IPv6 address then IPv6 will be used. If you specify an ipv6 'localaddr' then IPv6 will be used.
new
This method is deprecated. See the spawn() method instead.
Takes one argument: a name (kernel alias) which this new connection
will be known by. Returns a POE::Component::IRC object :)
Use of this method will generate a warning. There are currently no plans to
make it die() >;]
These are methods supported by the POE::Component::IRC object.
server_name
Takes no arguments. Returns the name of the IRC server that the component is currently connected to.
nick_name
Takes no arguments. Returns a scalar containing the current nickname that the bot is using.
session_id
Takes no arguments. Returns the ID of the component's session. Ideal for posting events to the component.
$kernel->post( $irc->session_id() => 'mode' => $channel => '+o' => $dude );
session_alias
Takes no arguments. Returns the session alias that has been set through
spawn()'s alias argument.
version
Takes no arguments. Returns the version number of the module.
send_queue
The component provides anti-flood throttling. This method takes no arguments and returns a scalar representing the number of messages that are queued up waiting for dispatch to the irc server.
connected
Takes no arguments. Returns true or false depending on whether the component is currently connected to an IRC network or not.
disconnect
Takes no arguments. Terminates the socket connection disgracefully >;o]
raw_events
With no arguments, returns true or false depending on whether irc_raw events
are being generated or not. Provide a true or false argument to enable or
disable this feature accordingly.
isupport
Takes one argument, a server capability to query. Returns undef on failure or a value representing the applicable capability. A full list of capabilities is available at http://www.irc.org/tech_docs/005.html.
isupport_dump_keys
Takes no arguments, returns a list of the available server capabilities keys,
which can be used with isupport().
yield
This method provides an alternative object based means of posting events to the component. First argument is the event to post, following arguments are sent as arguments to the resultant post.
$irc->yield(mode => $channel => '+o' => $dude);
call
This method provides an alternative object based means of calling events to the component. First argument is the event to call, following arguments are sent as arguments to the resultant call.
$irc->call(mode => $channel => '+o' => $dude);
delay
This method provides a way of posting delayed events to the component. The first argument is an arrayref consisting of the delayed command to post and any command arguments. The second argument is the time in seconds that one wishes to delay the command being posted.
my $alarm_id = $irc->delay( [ mode => $channel => '+o' => $dude ], 60 );
Returns an alarm ID that can be used with delay_remove() to cancel the delayed
event. This will be undefined if something went wrong.
delay_remove
This method removes a previously scheduled delayed event from the component.
Takes one argument, the alarm_id that was returned by a delay() method call.
my $arrayref = $irc->delay_remove( $alarm_id );
Returns an arrayref that was originally requested to be delayed.
resolver
Returns a reference to the POE::Component::Client::DNS object that is internally created by the component.
pipeline
Returns a reference to the POE::Component::IRC::Pipeline object used by the plugin system.
send_event
Sends an event through the components event handling system. These will get processed by plugins then by registered sessions. First argument is the event name, followed by any parameters for that event.
How to talk to your new IRC component... here's the events we'll accept.
These are events that are posted to the component, either via
$poe_kernel->post() or via the object method yield().
So the following would be functionally equivalent:
sub irc_001 { my ($kernel,$sender) = @_[KERNEL,SENDER]; my $irc = $sender->get_heap(); # obtain the poco's object
$irc->yield( privmsg => 'foo' => 'Howdy!' );
$kernel->post( $sender => privmsg => 'foo' => 'Howdy!' );
$kernel->post( $irc->session_id() => privmsg => 'foo' => 'Howdy!' );
$kernel->post( $irc->session_alias() => privmsg => 'foo' => 'Howdy!' );
return;
}
register
Takes N arguments: a list of event names that your session wants to listen for, minus the 'irc_' prefix. So, for instance, if you just want a bot that keeps track of which people are on a channel, you'll need to listen for JOINs, PARTs, QUITs, and KICKs to people on the channel you're in. You'd tell POE::Component::IRC that you want those events by saying this:
$kernel->post( 'my client', 'register', qw(join part quit kick) );
Then, whenever people enter or leave a channel your bot is on (forcibly
or not), your session will receive events with names like irc_join,
irc_kick, etc., which you can use to update a list of people on the
channel.
Registering for 'all' will cause it to send all IRC-related events to
you; this is the easiest way to handle it. See the test script for an
example.
Registering will generate an irc_registered event that your session can
trap. ARG0 is the components object. Useful if you want to bolt PoCo-IRC's
new features such as Plugins into a bot coded to the older deprecated API.
If you are using the new API, ignore this :)
Registering with multiple component sessions can be tricky, especially if one wants to marry up sessions/objects, etc. Check 'SIGNALS' section of this documentation for an alternative method of registering with multiple poco-ircs.
Starting with version 4.96, if you spawn the component from inside another POE
session, the component will automatically register that session as wanting 'all'
irc events. That session will receive an irc_registered event indicating that
the component is up and ready to go.
connect
Takes one argument: a hash reference of attributes for the new
connection, see spawn() for details. This event tells the IRC client to
connect to a new/different server. If it has a connection already open, it'll
close it gracefully before reconnecting.
ctcp and ctcpreply
Sends a CTCP query or response to the nick(s) or channel(s) which you specify. Takes 2 arguments: the nick or channel to send a message to (use an array reference here to specify multiple recipients), and the plain text of the message to send (the CTCP quoting will be handled for you). The "/me" command in popular IRC clients is actually a CTCP action.
# Doing a /me $irc->yield(ctcp => $channel => 'ACTION dances.');
join
Tells your IRC client to join a single channel of your choice. Takes at least one arg: the channel name (required) and the channel key (optional, for password-protected channels).
kick
Tell the IRC server to forcibly evict a user from a particular channel. Takes at least 2 arguments: a channel name, the nick of the user to boot, and an optional witty message to show them as they sail out the door.
remove (FreeNode only)
Tell the IRC server to forcibly evict a user from a particular channel. Takes at least 2 arguments: a channel name, the nick of the user to boot, and an optional witty message to show them as they sail out the door. Similar to KICK but does an enforced PART instead.
mode
Request a mode change on a particular channel or user. Takes at least one argument: the mode changes to effect, as a single string (e.g., "+sm-p+o"), and any number of optional operands to the mode changes (nicks, hostmasks, channel keys, whatever.) Or just pass them all as one big string and it'll still work, whatever. I regret that I haven't the patience now to write a detailed explanation, but serious IRC users know the details anyhow.
nick
Allows you to change your nickname. Takes exactly one argument: the new username that you'd like to be known as.
nickserv (FreeNode only)
Talks to FreeNode's NickServ. Takes any number of arguments.
notice
Sends a NOTICE message to the nick(s) or channel(s) which you specify. Takes 2 arguments: the nick or channel to send a notice to (use an array reference here to specify multiple recipients), and the text of the notice to send.
part
Tell your IRC client to leave the channels which you pass to it. Takes any number of arguments: channel names to depart from. If the last argument doesn't begin with a channel name identifier or contains a space character, it will be treated as a PART message and dealt with accordingly.
privmsg
Sends a public or private message to the nick(s) or channel(s) which you specify. Takes 2 arguments: the nick or channel to send a message to (use an array reference here to specify multiple recipients), and the text of the message to send.
Have a look at the constants in POE::Component::IRC::Common if you would like to use formatting and color codes in your messages.
quit
Tells the IRC server to disconnect you. Takes one optional argument:
some clever, witty string that other users in your channels will see
as you leave. You can expect to get an irc_disconnect event shortly
after sending this.
shutdown
By default, POE::Component::IRC sessions never go away. Even after
they're disconnected, they're still sitting around in the background,
waiting for you to call connect on them again to reconnect.
(Whether this behavior is the Right Thing is doubtful, but I don't want
to break backwards compatibility at this point.) You can send the IRC
session a shutdown event manually to make it delete itself.
If you are connected, shutdown will send a quit message to ircd and
disconnect. If you provide an argument that will be used as the QUIT
message.
Terminating multiple components can be tricky. Check the 'SIGNALS' section of this documentation for an alternative method of shutting down multiple poco-ircs.
topic
Retrieves or sets the topic for particular channel. If called with just the channel name as an argument, it will ask the server to return the current topic. If called with the channel name and a string, it will set the channel topic to that string. Supply an empty string to unset a channel topic.
unregister
Takes N arguments: a list of event names which you don't want to
receive. If you've previously done a register for a particular event
which you no longer care about, this event will tell the IRC
connection to stop sending them to you. (If you haven't, it just
ignores you. No big deal.)
If you have registered with 'all', attempting to unregister individual events such as 'mode', etc. will not work. This is a 'feature'.
debug
Takes one argument: 0 to turn debugging off or 1 to turn debugging on.
This flips the debugging flag in POE::Filter::IRC::Compat,
POE::Filter::CTCP,and POE::Component::IRC. This has the
same effect as setting Debug in spawn() or connect.
admin
Asks your server who your friendly neighborhood server administrators are. If you prefer, you can pass it a server name to query, instead of asking the server you're currently on.
away
When sent with an argument (a message describig where you went), the server will note that you're now away from your machine or otherwise preoccupied, and pass your message along to anyone who tries to communicate with you. When sent without arguments, it tells the server that you're back and paying attention.
dcc
Send a DCC SEND or CHAT request to another person. Takes at least two arguments: the nickname of the person to send the request to and the type of DCC request (SEND or CHAT). For SEND requests, be sure to add a third argument for the filename you want to send. Optionally, you can add a fourth argument for the DCC transfer blocksize, but the default of 1024 should usually be fine.
Incidentally, you can send other weird nonstandard kinds of DCCs too;
just put something besides 'SEND' or 'CHAT' (say, 'FOO') in the type
field, and you'll get back irc_dcc_foo events when activity happens
on its DCC connection.
If you are behind a firewall or Network Address Translation, you may want to
consult connect for some parameters that are useful with this command.
dcc_accept
Accepts an incoming DCC connection from another host. First argument:
the magic cookie from an irc_dcc_request event. In the case of a DCC
GET, the second argument can optionally specify a new name for the
destination file of the DCC transfer, instead of using the sender's name
for it. (See the irc_dcc_request section below for more details.)
dcc_resume
Resumes a DCC SEND file transfer. First argument: the magic cookie from an
irc_dcc_request event. The second argument is the name of the file to which
you want to write. The third argument is the size from which will be resumed.
dcc_chat
Sends lines of data to the person on the other side of a DCC CHAT
connection. Takes any number of arguments: the magic cookie from an
irc_dcc_start event, followed by the data you wish to send. (It'll be
chunked into lines by a POE::Filter::Line for you,
don't worry.)
dcc_close
Terminates a DCC SEND or GET connection prematurely, and causes DCC CHAT
connections to close gracefully. Takes one argument: the magic cookie
from an irc_dcc_start or irc_dcc_request event.
info
Basically the same as the "version" command, except that the server is permitted to return any information about itself that it thinks is relevant. There's some nice, specific standards-writing for ya, eh?
invite
Invites another user onto an invite-only channel. Takes 2 arguments: the nick of the user you wish to admit, and the name of the channel to invite them to.
ison
Asks the IRC server which users out of a list of nicknames are currently online. Takes any number of arguments: a list of nicknames to query the IRC server about.
links
Asks the server for a list of servers connected to the IRC network. Takes two optional arguments, which I'm too lazy to document here, so all you would-be linklooker writers should probably go dig up the RFC.
list
Asks the server for a list of visible channels and their topics. Takes any number of optional arguments: names of channels to get topic information for. If called without any channel names, it'll list every visible channel on the IRC network. This is usually a really big list, so don't do this often.
motd
Request the server's "Message of the Day", a document which typically contains stuff like the server's acceptable use policy and admin contact email addresses, et cetera. Normally you'll automatically receive this when you log into a server, but if you want it again, here's how to do it. If you'd like to get the MOTD for a server other than the one you're logged into, pass it the server's hostname as an argument; otherwise, no arguments.
names
Asks the server for a list of nicknames on particular channels. Takes any number of arguments: names of channels to get lists of users for. If called without any channel names, it'll tell you the nicks of everyone on the IRC network. This is a really big list, so don't do this much.
quote
Sends a raw line of text to the server. Takes one argument: a string of a raw IRC command to send to the server. It is more optimal to use the events this module supplies instead of writing raw IRC commands yourself.
stats
Returns some information about a server. Kinda complicated and not terribly commonly used, so look it up in the RFC if you're curious. Takes as many arguments as you please.
time
Asks the server what time it thinks it is, which it will return in a human-readable form. Takes one optional argument: a server name to query. If not supplied, defaults to current server.
trace
If you pass a server name or nick along with this request, it asks the server for the list of servers in between you and the thing you mentioned. If sent with no arguments, it will show you all the servers which are connected to your current server.
userhost
Asks the IRC server for information about particular nicknames. (The RFC doesn't define exactly what this is supposed to return.) Takes any number of arguments: the nicknames to look up.
users
Asks the server how many users are logged into it. Defaults to the server you're currently logged into; however, you can pass a server name as the first argument to query some other machine instead.
version
Asks the server about the version of ircd that it's running. Takes one optional argument: a server name to query. If not supplied, defaults to current server.
who
Lists the logged-on users matching a particular channel name, hostname, nickname, or what-have-you. Takes one optional argument: a string for it to search for. Wildcards are allowed; in the absence of this argument, it will return everyone who's currently logged in (bad move). Tack an "o" on the end if you want to list only IRCops, as per the RFC.
whois
Queries the IRC server for detailed information about a particular
user. Takes any number of arguments: nicknames or hostmasks to ask for
information about. As of version 3.2, you will receive an irc_whois
event in addition to the usual numeric responses. See below for details.
whowas
Asks the server for information about nickname which is no longer
connected. Takes at least one argument: a nickname to look up (no
wildcards allowed), the optional maximum number of history entries to
return, and the optional server hostname to query. As of version 3.2,
you will receive an irc_whowas event in addition to the usual numeric
responses. See below for details.
ping and pong
Included for completeness sake. The component will deal with ponging to pings automatically. Don't worry about it.
locops
Opers-only command. This one sends a message to all currently logged-on local-opers (+l). This option is specific to EFNet.
oper
In the exceedingly unlikely event that you happen to be an IRC operator, you can use this command to authenticate with your IRC server. Takes 2 arguments: your username and your password.
operwall
Opers-only command. This one sends a message to all currently logged-on global opers. This option is specific to EFNet.
rehash
Tells the IRC server you're connected to, to rehash its configuration files. Only useful for IRCops. Takes no arguments.
die
Tells the IRC server you're connect to, to terminate. Only useful for IRCops, thank goodness. Takes no arguments.
restart
Tells the IRC server you're connected to, to shut down and restart itself. Only useful for IRCops, thank goodness. Takes no arguments.
sconnect
Tells one IRC server (which you have operator status on) to connect to
another. This is actually the CONNECT command, but I already had an
event called connect, so too bad. Takes the args you'd expect: a
server to connect to, an optional port to connect on, and an optional
remote server to connect with, instead of the one you're currently on.
summon
Don't even ask.
wallops
Another opers-only command. This one sends a message to all currently logged-on opers (and +w users); sort of a mass PA system for the IRC server administrators. Takes one argument: some clever, witty message to send.
The events you will receive (or can ask to receive) from your running IRC component. Note that all incoming event names your session will receive are prefixed by 'irc_', to inhibit event namespace pollution.
If you wish, you can ask the client to send you every event it generates. Simply register for the event name "all". This is a lot easier than writing a huge list of things you specifically want to listen for. FIXME: I'd really like to classify these somewhat ("basic", "oper", "ctcp", "dcc", "raw" or some such), and I'd welcome suggestions for ways to make this easier on the user, if you can think of some.
In your event handlers, $_[SENDER] is the particular component session that
sent you the event. $_[SENDER]->get_heap() will retrieve the component's
object. Useful if you want on-the-fly access to the object and its methods.
irc_connected
The IRC component will send an irc_connected event as soon as it
establishes a connection to an IRC server, before attempting to log
in. ARG0 is the server name.
NOTE: When you get an irc_connected event, this doesn't mean you
can start sending commands to the server yet. Wait until you receive
an irc_001 event (the server welcome message) before actually sending
anything back to the server.
irc_ctcp
irc_ctcp events are generated upon receipt of CTCP messages, in addition to
the irc_ctcp_* events mentioned below. They are identical in every way to
these, with one difference: instead of the * being in the method name, it
is prepended to the argument list. For example, if someone types /ctcp
Flibble foo bar, an irc_ctcp event will be sent with foo as ARG0,
and the rest as given below.
It is not recommended that you register for both irc_ctcp and irc_ctcp_*
events, since they will both be fired and presumably cause duplication.
irc_ctcp_*
irc_ctcp_whatever events are generated upon receipt of CTCP messages.
For instance, receiving a CTCP PING request generates an irc_ctcp_ping
event, CTCP ACTION (produced by typing "/me" in most IRC clients)
generates an irc_ctcp_action event, blah blah, so on and so forth. ARG0
is the nick!hostmask of the sender. ARG1 is the channel/recipient
name(s). ARG2 is the text of the CTCP message.
Note that DCCs are handled separately -- see the irc_dcc_request
event, below.
irc_ctcpreply_*
irc_ctcpreply_whatever messages are just like irc_ctcp_whatever
messages, described above, except that they're generated when a response
to one of your CTCP queries comes back. They have the same arguments and
such as irc_ctcp_* events.
irc_disconnected
The counterpart to irc_connected, sent whenever a socket connection
to an IRC server closes down (whether intentionally or
unintentionally). ARG0 is the server name.
irc_error
You get this whenever the server sends you an ERROR message. Expect this to usually be accompanied by the sudden dropping of your connection. ARG0 is the server's explanation of the error.
irc_join
Sent whenever someone joins a channel that you're on. ARG0 is the person's nick!hostmask. ARG1 is the channel name.
irc_invite
Sent whenever someone offers you an invitation to another channel. ARG0 is the person's nick!hostmask. ARG1 is the name of the channel they want you to join.
irc_kick
Sent whenever someone gets booted off a channel that you're on. ARG0 is the kicker's nick!hostmask. ARG1 is the channel name. ARG2 is the nick of the unfortunate kickee. ARG3 is the explanation string for the kick.
irc_mode
Sent whenever someone changes a channel mode in your presence, or when you change your own user mode. ARG0 is the nick!hostmask of that someone. ARG1 is the channel it affects (or your nick, if it's a user mode change). ARG2 is the mode string (i.e., "+o-b"). The rest of the args (ARG3 .. $#_) are the operands to the mode string (nicks, hostmasks, channel keys, whatever).
irc_msg
Sent whenever you receive a PRIVMSG command that was addressed to you privately. ARG0 is the nick!hostmask of the sender. ARG1 is an array reference containing the nick(s) of the recipients. ARG2 is the text of the message.
irc_nick
Sent whenever you, or someone around you, changes nicks. ARG0 is the nick!hostmask of the changer. ARG1 is the new nick that they changed to.
irc_notice
Sent whenever you receive a NOTICE command. ARG0 is the nick!hostmask of the sender. ARG1 is an array reference containing the nick(s) or channel name(s) of the recipients. ARG2 is the text of the NOTICE message.
irc_part
Sent whenever someone leaves a channel that you're on. ARG0 is the person's nick!hostmask. ARG1 is the channel name. ARG2 is the part message.
irc_ping
An event sent whenever the server sends a PING query to the client. (Don't confuse this with a CTCP PING, which is another beast entirely. If unclear, read the RFC.) Note that POE::Component::IRC will automatically take care of sending the PONG response back to the server for you, although you can still register to catch the event for informational purposes.
irc_public
Sent whenever you receive a PRIVMSG command that was sent to a channel. ARG0 is the nick!hostmask of the sender. ARG1 is an array reference containing the channel name(s) of the recipients. ARG2 is the text of the message.
irc_quit
Sent whenever someone on a channel with you quits IRC (or gets KILLed). ARG0 is the nick!hostmask of the person in question. ARG1 is the clever, witty message they left behind on the way out.
irc_socketerr
Sent when a connection couldn't be established to the IRC server. ARG0 is probably some vague and/or misleading reason for what failed.
irc_topic
Sent when a channel topic is set or unset. ARG0 is the nick!hostmask of the sender. ARG1 is the channel affected. ARG2 will be either: a string if the topic is being set; or a zero-length string (i.e. '') if the topic is being unset. Note: replies to queries about what a channel topic *is* (i.e. TOPIC #channel) , are returned as numerics, not with this event.
irc_whois
Sent in response to a 'whois' query. ARG0 is a hashref, with the following keys:
'nick', the users nickname;
'user', the users username;
'host', their hostname;
'real', their real name;
'idle', their idle time in seconds;
'signon', the epoch time they signed on (will be undef if ircd does not support this);
'channels', an arrayref listing visible channels they are on, the channel is prefixed with '@','+','%' depending on whether they have +o +v or +h;
'server', their server ( might not be useful on some networks );
'oper', whether they are an IRCop, contains the IRC operator string if they are, undef if they aren't.
'actually', some ircds report the users actual ip address, that'll be here;
On Freenode if the user has identified with NICKSERV there will be an additional key:
'identified'.
irc_whowas
Similar to the above, except some keys will be missing.
irc_raw
Enabled by passing Raw = 1> to spawn() or connect, ARG0 is the raw IRC
string received by the component from the IRC server, before it has been
mangled by filters and such like.
irc_registered
Sent once to the requesting session on registration ( see register ). ARG0
is a reference tothe component's object.
irc_shutdown
Sent to all registered sessions when the component has been asked to
shutdown. ARG0 will be the session ID of the requesting session.
irc_isupport
Emitted by the first event after an irc_005, to indicate that isupport
information has been gathered. ARG0 is the
POE::Component::IRC::Plugin::ISupport
object.
irc_delay_set
Emitted on a succesful addition of a delayed event using delay() method. ARG0
will be the alarm_id which can be used later with delay_remove(). Subsequent
parameters are the arguments that were passed to delay().
irc_delay_removed
Emitted when a delayed command is successfully removed. ARG0 will be the
alarm_id that was removed. Subsequent parameters are the arguments that were
passed to delay().
irc_socks_failed
Emitted whenever we fail to connect successfully to a SOCKS server or the SOCKS server is not actually a SOCKS server. ARG0 will be some vague reason as to what went wrong. Hopefully.
irc_socks_rejected
Emitted whenever a SOCKS connection is rejected by a SOCKS server. ARG0 is the SOCKS code, ARG1 the SOCKS server address, ARG2 the SOCKS port and ARG3 the SOCKS user id ( if defined ).
Most messages from IRC servers are identified only by three-digit
numeric codes with undescriptive constant names like RPL_UMODEIS and
ERR_NOTOPLEVEL. (Actually, the list of codes in the RFC is kind of
out-of-date... the list in the back of Net::IRC::Event.pm is more
complete, and different IRC networks have different and incompatible
lists. Ack!) As an example, say you wanted to handle event 376
(RPL_ENDOFMOTD, which signals the end of the MOTD message). You'd
register for '376', and listen for irc_376 events. Simple, no? ARG0
is the name of the server which sent the message. ARG1 is the text of
the message. ARG2 is an ARRAYREF of the parsed message, so there is no
need to parse ARG1 yourself.
irc_dcc_chat
Notifies you that one line of text has been received from the client on the other end of a DCC CHAT connection. ARG0 is the connection's magic cookie, ARG1 is the nick of the person on the other end, ARG2 is the port number, and ARG3 is the text they sent.
irc_dcc_done
You receive this event when a DCC connection terminates normally.
Abnormal terminations are reported by irc_dcc_error, below. ARG0 is
the connection's magic cookie, ARG1 is the nick of the person on the
other end, ARG2 is the DCC type (CHAT, SEND, GET, etc.), and ARG3 is the
port number. For DCC SEND and GET connections, ARG4 will be the
filename, ARG5 will be the file size, and ARG6 will be the number of
bytes transferred. (ARG5 and ARG6 should always be the same.)
irc_dcc_failed
You get this event when a DCC connection fails for some reason. ARG0 will be the operation that failed, ARG1 is the error number, ARG2 is the description of the error and ARG3 the connection's magic cookie.
irc_dcc_error
You get this event whenever a DCC connection or connection attempt terminates unexpectedly or suffers some fatal error. ARG0 will be the connection's magic cookie, ARG1 will be a string describing the error. ARG2 will be the nick of the person on the other end of the connection. ARG3 is the DCC type (SEND, GET, CHAT, etc.). ARG4 is the port number of the DCC connection, if any. For SEND and GET connections, ARG5 is the filename, ARG6 is the expected file size, and ARG7 is the transfered size.
irc_dcc_get
Notifies you that another block of data has been successfully transferred from the client on the other end of your DCC GET connection. ARG0 is the connection's magic cookie, ARG1 is the nick of the person on the other end, ARG2 is the port number, ARG3 is the filename, ARG4 is the total file size, and ARG5 is the number of bytes successfully transferred so far.
irc_dcc_request
You receive this event when another IRC client sends you a DCC SEND or
CHAT request out of the blue. You can examine the request and decide
whether or not to accept it here. ARG0 is the nick of the client on the
other end. ARG1 is the type of DCC request (CHAT, SEND, etc.). ARG2 is
the port number. ARG3 is a "magic cookie" argument, suitable for sending
with dcc_accept events to signify that you want to accept the
connection (see the 'dcc_accept' docs). For DCC SEND and GET
connections, ARG4 will be the filename, and ARG5 will be the file size.
irc_dcc_send
Notifies you that another block of data has been successfully transferred from you to the client on the other end of a DCC SEND connection. ARG0 is the connection's magic cookie, ARG1 is the nick of the person on the other end, ARG2 is the port number, ARG3 is the filename, ARG4 is the total file size, and ARG5 is the number of bytes successfully transferred so far.
irc_dcc_start
This event notifies you that a DCC connection has been successfully
established. ARG0 is a unique "magic cookie" argument which you can pass
to dcc_chat or dcc_close. ARG1 is the nick of the person on the
other end, ARG2 is the DCC type (CHAT, SEND, GET, etc.), and ARG3 is the
port number. For DCC SEND and GET connections, ARG4 will be the filename
and ARG5 will be the file size.
irc_snotice
A weird, non-RFC-compliant message from an IRC server. Don't worry about it. ARG0 is the text of the server's message.
The component will handle a number of custom signals that you may send using
POE::Kernel signal() method.
POCOIRC_REGISTER
Registering with multiple PoCo-IRC components has been a pita. Well, no more, using the power of POE::Kernel signals.
If the component receives a POCOIRC_REGISTER signal it'll register the
requesting session and trigger an irc_registered event. From that event one
can get all the information necessary such as the poco-irc object and the
SENDER session to do whatever one needs to build a poco-irc dispatch table.
The way the signal handler in PoCo-IRC is written also supports sending the
POCOIRC_REGISTER to multiple sessions simultaneously, by sending the signal
to the POE Kernel itself.
Pass the signal your session, session ID or alias, and the IRC events (as
specified to register).
To register with multiple PoCo-IRCs one can do the following in your session's _start handler:
sub _start { my ($kernel, $session) = @_[KERNEL, SESSION];
# Registering with multiple pocoircs for 'all' IRC events
$kernel->signal( $kernel, 'POCOIRC_REGISTER', $session->ID(), 'all' );
return:
}
Each poco-irc will send your session an irc_registered event:
sub irc_registered { my ($kernel, $sender, $heap, $irc_object) = @_[KERNEL, SENDER, HEAP, ARG0];
# Get the poco-irc session ID
my $sender_id = $sender->ID();
# Or it's alias
my $poco_alias = $irc_object->session_alias();
# Store it in our heap maybe
$heap->{irc_objects}->{ $sender_id } = $irc_object;
# Make the poco connect
$irc_object->yield( connect => { } );
return;
}
POCOIRC_SHUTDOWN
Telling multiple poco-ircs to shutdown was a pita as well. The same principle as with registering applies to shutdown too.
Send a POCOIRC_SHUTDOWN to the POE Kernel to terminate all the active
poco-ircs simultaneously.
$poe_kernel->signal( $poe_kernel, 'POCOIRC_SHUTDOWN' );
Any additional parameters passed to the signal will become your quit messages on each IRC network.
A few have turned up in the past and they are sure to again. Please use http://rt.cpan.org/ to report any. Alternatively, email the current maintainer.
Chris BinGOs Williams <chris@bingosnet.co.uk>
Hinrik Örn Sigurðsson <hinrik.sig@gmail.com>
Dennis Taylor.
Copyright (c) Dennis Taylor, Chris Williams and Hinrik Örn Sigurðsson
This module may be used, modified, and distributed under the same terms as Perl itself. Please see the license that came with your Perl distribution for details.
The maddest of mad props go out to Rocco "dngor" Caputo <troc@netrus.net>, for inventing something as mind-bogglingly cool as POE, and to Kevin "oznoid" Lenzo <lenzo@cs.cmu.edu>, for being the attentive parent of our precocious little infobot on #perl.
Further props to a few of the studly bughunters who made this module not suck: Abys <abys@web1-2-3.com>, Addi <addi@umich.edu>, ResDev <ben@reser.org>, and Roderick <roderick@argon.org>. Woohoo!
Kudos to Apocalypse, <apocal@cpan.org>, for the plugin system and to Jeff 'japhy' Pinyan, <japhy@perlmonk.org>, for Pipeline.
Thanks to the merry band of POE pixies from #PoE @ irc.perl.org, including ( but not limited to ), ketas, ct, dec, integral, webfox, immute, perigrin, paulv, alias.
Check out the Changes file for further contributors.
RFC 1459 http://www.faqs.org/rfcs/rfc1459.html
Some good examples reside in the POE cookbook which has a whole section devoted to IRC programming http://poe.perl.org/.
The examples/ folder of this distribution.
The #poe channel on irc.freenode.org.