POE::Component::IRC(3pUser Contributed Perl DocumentatiPOE::Component::IRC(3p)



NAME
       POE::Component::IRC - A fully event-driven IRC client module

SYNOPSIS
        # 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;
        }

DESCRIPTION
       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.

   Useful subclasses
       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
           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
           POE::Component::IRC::Qnet is POE::Component::IRC tweaked for use on
           Quakenet IRC network.

       POE::Component::IRC::Qnet::State
           POE::Component::IRC::Qnet::State is a tweaked version of
           POE::Component::IRC::State for use on the Quakenet IRC network.

   The Plugin system
       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:

       POE::Component::IRC::Plugin::DCC
           Provides DCC support. Loaded by default.

       POE::Component::IRC::Plugin::AutoJoin
           Keeps you on your favorite channels throughout reconnects and even
           kicks.

       POE::Component::IRC::Plugin::Connector
           Glues an irc bot to an IRC network, i.e. deals with maintaining
           ircd connections.

       POE::Component::IRC::Plugin::BotTraffic
           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.

       POE::Component::IRC::Plugin::BotAddressed
           Generates "irc_bot_addressed" / "irc_bot_mentioned" /
           "irc_bot_mentioned_action" events whenever your bot's name comes up
           in channel discussion.

       POE::Component::IRC::Plugin::BotCommand
           Provides an easy way to handle commands issued to your bot.

       POE::Component::IRC::Plugin::Console
           See inside the component. See what events are being sent. Generate
           irc commands manually. A TCP based console.

       POE::Component::IRC::Plugin::FollowTail
           Follow the tail of an ever-growing file.

       POE::Component::IRC::Plugin::Logger
           Log public and private messages to disk.

       POE::Component::IRC::Plugin::NickServID
           Identify with FreeNode's NickServ when needed.

       POE::Component::IRC::Plugin::Proxy
           A lightweight IRC proxy/bouncer.

       POE::Component::IRC::Plugin::CTCP
           Automagically generates replies to ctcp version, time and userinfo
           queries.

       POE::Component::IRC::Plugin::PlugMan
           An experimental Plugin Manager plugin.

       POE::Component::IRC::Plugin::NickReclaim
           Automagically deals with your nickname being in use and reclaiming
           it.

       POE::Component::IRC::Plugin::CycleEmpty
           Cycles (parts and rejoins) channels if they become empty and
           opless, in order to gain ops.

CONSTRUCTORS
       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. All the options
       below may be supplied to the "connect" input event as well, except for
       'alias', 'options', 'NoDNS', 'debug', and 'plugin_debug'.

       '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"
       and "irc_raw_out" 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 when you try to send a message that's too long.

       'debug', if set to a true value causes the IRC component to print every
       message sent to and from the server, as well as print some warnings
       when it receives malformed messages. This option will be enabled if the
       "POCOIRC_DEBUG" environment variable is set to a true value.

       'plugin_debug', set to some true value to print plugin debug info,
       default 0.  Plugins are processed inside an eval. When you enable this
       option, you will be notified when (and why) a plugin raises an
       exception. This option will be enabled if the "POCOIRC_DEBUG"
       environment variable is set to a true value.

       '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.

       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 connections. '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, specifying 'UseSSL' will do nothing. The
       default is to not try to use SSL.

       'Resolver', requires a POE::Component::Client::DNS object. Useful when
       spawning multiple poco-irc sessions, saves the overhead of multiple dns
       sessions.

       '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.

       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.  The first
       argument should be a name (kernel alias) which this new connection will
       be known by. Optionally takes more arguments (see "spawn" as name/value
       pairs. Returns a POE::Component::IRC object. :)

       Note: Use of this method will generate a warning. There are currently
       no plans to make it die() >;]

METHODS
       These are methods supported by the POE::Component::IRC object. It also
       inherits a few from Object::Pluggable.  See its documentation for
       details.

   "server_name"
       Takes no arguments. Returns the name of the IRC server that the
       component is currently connected to.

   "server_version"
       Takes no arguments. Returns the IRC server version.

   "nick_name"
       Takes no arguments. Returns a scalar containing the current nickname
       that the bot is using.

   "localaddr"
       Takes no arguments. Returns the IP address being used.

   "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.

   "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.

   "logged_in"
       Takes no arguments. Returns true or false depending on whether the IRC
       component is logged into an IRC network.

   "connected"
       Takes no arguments. Returns true or false depending on whether the
       component's socket is currently connected.

   "disconnect"
       Takes no arguments. Terminates the socket connection disgracefully >;o]

   "raw_events"
       With no arguments, returns true or false depending on whether "irc_raw"
       and "irc_raw_out" 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.

   "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.

INPUT
       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;
        }

   Important Commands
       "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 the SIGNALS
       section 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.
       "#mychan +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, ratbox, et al)

       Talks to 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_disconnected" 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 logged into an IRC server, "shutdown" first will send a quit
       message and wait to be disconnected. It will wait for up to 5 seconds
       before forcibly disconnecting from the IRC server. If you provide an
       argument, that will be used as the QUIT message. If you provide two
       arguments, the second one will be used as the timeout (in seconds).

       Terminating multiple components can be tricky. Check the SIGNALS
       section for a 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::IRCD,
       POE::Filter::IRC::Compat, and POE::Component::IRC. This has the same
       effect as setting Debug in "spawn" or "connect".

   Not-So-Important Commands
       "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.

       "cap"

       Used to query/enable/disable IRC protocol capabilities. Takes any
       number of arguments.

       "dcc*"

       See the DCC plugin (loaded by default) documentation for DCC-related
       commands.

       "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.

       "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.

   Purely Esoteric Commands
       "die"

       Tells the IRC server you're connect to, to terminate. Only useful for
       IRCops, thank goodness. Takes no arguments.

       "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.

       "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.

       "squit"

       Operator-only command used to disconnect server links. Takes two
       arguments, the server to disconnect and a message explaining your
       action.

       "summon"

       Don't even ask.

       "servlist"

       Lists the currently connected services on the network that are visible
       to you.  Takes two optional arguments, a mask for matching service
       names against, and a service type.

       "squery"

       Sends a message to a service. Takes the same arguments as "privmsg".

       "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.

       "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.

OUTPUT
       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.

   Important Events
       "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. On
       servers supporting the IDENTIFY-MSG feature (e.g. FreeNode), CTCP
       ACTIONs will have "ARG3", which will be 1 if the sender has identified
       with NickServ, 0 otherwise.

       Note that DCCs are handled separately -- see the DCC plugin.

       "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. On servers supporting the IDENTIFY-MSG feature
       (e.g.  FreeNode), there will be an additional argument, "ARG3", will be
       1 if the sender has identified with NickServ, 0 otherwise.

       "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_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. On servers supporting the IDENTIFY-MSG feature (e.g.
       FreeNode), there will be an additional argument, "ARG3", will be 1 if
       the sender has identified with NickServ, 0 otherwise.

       "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 ircu/seven IRCDs (e.g. FreeNode), if the user has registered with
       services, there will be another key:

       'account'.

       On Hyperion IRCDs, 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", or by calling
       "raw_events" with a true argument. "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_raw_out"

       Enabled by passing "Raw => 1" to "spawn" or "connect", or by calling
       "raw_events" with a true argument. "ARG0" is the raw IRC string sent by
       the component to the the IRC server.

       "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 successful addition of a delayed event using the "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).

   Somewhat Less Important Events
       "irc_cap"

       A reply from the server regarding protocol capabilities. "ARG0" is the
       CAP subcommand (e.g. 'LS'). "ARG1" is the result of the subcommand,
       unless this is a multi-part reply, in which case "ARG1" is '*' and
       "ARG2" contains the result.

       "irc_dcc_*"

       See the DCC plugin (loaded by default) documentation for DCC-related
       events.

       "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_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.

   All numeric events
       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 array reference of the parsed message, so there is no need
       to parse "ARG1" yourself.

SIGNALS
       The component will handle a number of custom signals that you may send
       using POE::Kernel's "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.

ENCODING AND CHARACTER SETS
   Messages
       The only requirement the IRC protocol places on its messages is that
       they be 8-bits, and in ASCII. This has resulted in most of the Western
       world settling on ASCII-compatible Latin-1 (usually Microsoft's CP1252,
       a Latin-1 variant) as a convention. Recently, popular IRC clients
       (mIRC, xchat, certain irssi configurations) have begun sending a
       mixture of CP1252 and UTF-8 over the wire to allow more characters
       without breaking backward compatibility (too much).  They send CP1252
       encoded messages if the characters fit within that encoding, otherwise
       falling back to UTF-8. Writing text with mixed encoding to a file,
       terminal, or database is rarely a good idea. To decode such messages
       reliably, see "irc_to_utf8" from POE::Component::IRC::Common.

   Channel names
       This matter is complicated further by the fact that some servers allow
       non-ASCII characters in channel names. The IRC component doesn't
       explicitly convert between encodings before sending your message along,
       but it has to concatenate the channel name and the message before
       sending them over the wire. So when you do "$irc->yield(privmsg =>
       $chan, 'ae`i')", where $chan is the unmodified channel name you got
       from the IRC component (i.e. it's a byte string), the channel name will
       end up getting double-encoded when concatenated with the message (which
       is a text string).  If the channel name is all-ASCII, then nothing bad
       will happen, but if there are non-ASCII chars in it, you're in trouble.

       To prevent this, you can't simply call "irc_to_utf8" on the channel
       name and then use it, because IRC servers don't care about encodings.
       '#ae`i' in CP1252 is not the same channel as '#ae`i' in UTF-8. The
       channel name and your message must therefore both be byte stirngs, or
       both be text strings.  If they're text strings, the UTF-8 flag must be
       off for both, or on for both.

       A simple rule to follow is to call "encode_utf8" on the channel name
       and/or message if they are text strings. Here are some examples:

        use Encode qw(encode_utf8);

        sub irc_public {
            my ($who, $where, $what) = @_[ARG0..ARG2];
            my $irc = $_[SENDER]->get_heap();

            # bad: if $where has any non-ASCII chars, they will get double-encoded
            $irc->yield(privmsg => $where, 'ae`i');

            # bad: if $what has any non-ASCII chars, they will get double-encoded
            $irc->yield(privmsg => '#ae`i', $what);

            # good: both are byte strings already, so this does what we expect
            $irc->yield(privmsg => $where, $what);

            # good: both are text strings (Latin1 as per Perl's default), so
            # they'll be concatenated correctly
            $irc->yield(privmsg => '#ae`i', 'ae`i');

            # good: same as the last one, except now they're both in UTF-8,
            # which means we'll be sending the message to a different channel
            use utf8;
            $irc->yield(privmsg => '#ae`i', 'ae`i');

            # good: $where and $msg_bytes are both byte strings
            my $msg_bytes = encode_utf8('ae`i');
            $irc->yield(privmsg => $where, $msg_bytes);

            # good: $chan_bytes and $what are both byte strings
            my $chan_bytes = encode_utf8('#ae`i');
            $irc->yield(privmsg => $chan_bytes, $what);
        }

       See also Encode, perluniintro, perlunitut, perlunicode, and perlunifaq.

BUGS
       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.

DEVELOPMENT
       You can find the latest source on github:
       http://github.com/bingos/poe-component-irc
       <http://github.com/bingos/poe-component-irc>

       The project's developers usually hang out in the "#poe" IRC channel on
       irc.freenode.org. Do drop us a line.

MAINTAINERS
       Chris "BinGOs" Williams <chris@bingosnet.co.uk>

       Hinrik Oern Sigur`sson <hinrik.sig@gmail.com>

AUTHOR
       Dennis Taylor.

LICENCE
       Copyright (c) Dennis Taylor, Chris Williams and Hinrik Oern 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.

MAD PROPS
       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.

SEE ALSO
       RFC 1459 <http://www.faqs.org/rfcs/rfc1459.html>

       <http://www.irchelp.org/>,

       <http://poe.perl.org/>,

       <http://www.infobot.org/>,

       Some good examples reside in the POE cookbook which has a whole section
       devoted to IRC programming <http://poe.perl.org/?POE_Cookbook>.

       The examples/ folder of this distribution.



perl v5.12.2                      2010-11-05           POE::Component::IRC(3p)
