Provided by: libpoe-component-irc-perl_6.90+dfsg-1_all bug

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.perl.org';

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

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

       ·   'Bitmode', an integer representing your initial user modes set in the USER command.
           See RFC 2812. If you do not set this, 8 (+i) will be used.

       ·   'UseSSL', set to some true value if you want to connect using SSL.

       ·   'SSLCert', set to a SSL Certificate(PAM encoded) to connect using a client cert

       ·   'SSLKey', set to a SSL Key(PAM encoded) to connect using a client cert

       ·   'SSLCtx', set to a SSL Context to configure the SSL Connection

           The 'SSLCert' and 'SSLKey' both need to be specified. The 'SSLCtx' takes precedence
           specified.

       ·   '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', 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.  Default is false.

           Two new attributes are 'Proxy' and 'ProxyPort' for sending your =item * '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.

       ·   'webirc', enable the use of WEBIRC to spoof host/IP.  You must have a WEBIRC password
           set up on the IRC server/network (so will only work for servers which trust you to
           spoof the IP & host the connection is from) - value should be a hashref containing
           keys "pass", "user", "host" and "ip".

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

       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'. Perl >=5.14 or Socket6 (for older Perls) is
       required. If you that 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

   Information
       "server"

       Takes no arguments. Returns the server host we are currently connected to (or trying to
       connect to).

       "port"

       Takes no arguments. Returns the server port we are currently connected to (or trying to
       connect to).

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

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

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

       "resolver"

       Returns a reference to the POE::Component::Client::DNS object that is internally created
       by the component.

   Events
       "session_id"

       Inherited from POE::Component::Syndicator

       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"

       Inherited from POE::Component::Syndicator

       Takes no arguments. Returns the session alias that has been set through "spawn"'s 'alias'
       argument.

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

       "yield"

       Inherited from POE::Component::Syndicator

       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"

       Inherited from POE::Component::Syndicator

       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"

       Inherited from POE::Component::Syndicator

       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"

       Inherited from POE::Component::Syndicator

       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.

       "send_event"

       Inherited from POE::Component::Syndicator

       Sends an event through the component's 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.

       "send_event_next"

       Inherited from POE::Component::Syndicator

       This sends an event right after the one that's currently being processed.  Useful if you
       want to generate some event which is directly related to another event so you want them to
       appear together. This method can only be called when POE::Component::IRC is processing an
       event, e.g. from one of your event handlers. Takes the same arguments as "send_event".

       "send_event_now"

       Inherited from POE::Component::Syndicator

       This will send an event to be processed immediately. This means that if an event is
       currently being processed and there are plugins or sessions which will receive it after
       you do, then an event sent with "send_event_now" will be received by those
       plugins/sessions before the current event. Takes the same arguments as "send_event".

   Plugins
       "pipeline"

       Inherited from Object::Pluggable

       Returns the Object::Pluggable::Pipeline object.

       "plugin_add"

       Inherited from Object::Pluggable

       Accepts two arguments:

        The alias for the plugin
        The actual plugin object
        Any number of extra arguments

       The alias is there for the user to refer to it, as it is possible to have multiple plugins
       of the same kind active in one Object::Pluggable object.

       This method goes through the pipeline's "push()" method, which will call
       "$plugin->plugin_register($pluggable, @args)".

       Returns the number of plugins now in the pipeline if plugin was initialized, "undef"/an
       empty list if not.

       "plugin_del"

       Inherited from Object::Pluggable

       Accepts the following arguments:

        The alias for the plugin or the plugin object itself
        Any number of extra arguments

       This method goes through the pipeline's "remove()" method, which will call
       "$plugin->plugin_unregister($pluggable, @args)".

       Returns the plugin object if the plugin was removed, "undef"/an empty list if not.

       "plugin_get"

       Inherited from Object::Pluggable

       Accepts the following arguments:

        The alias for the plugin

       This method goes through the pipeline's "get()" method.

       Returns the plugin object if it was found, "undef"/an empty list if not.

       "plugin_list"

       Inherited from Object::Pluggable

       Takes no arguments.

       Returns a hashref of plugin objects, keyed on alias, or an empty list if there are no
       plugins loaded.

       "plugin_order"

       Inherited from Object::Pluggable

       Takes no arguments.

       Returns an arrayref of plugin objects, in the order which they are encountered in the
       pipeline.

       "plugin_register"

       Inherited from Object::Pluggable

       Accepts the following arguments:

        The plugin object
        The type of the hook (the hook types are specified with _pluggable_init()'s 'types')
        The event name[s] to watch

       The event names can be as many as possible, or an arrayref. They correspond to the
       prefixed events and naturally, arbitrary events too.

       You do not need to supply events with the prefix in front of them, just the names.

       It is possible to register for all events by specifying 'all' as an event.

       Returns 1 if everything checked out fine, "undef"/an empty list if something is seriously
       wrong.

       "plugin_unregister"

       Inherited from Object::Pluggable

       Accepts the following arguments:

        The plugin object
        The type of the hook (the hook types are specified with _pluggable_init()'s 'types')
        The event name[s] to unwatch

       The event names can be as many as possible, or an arrayref. They correspond to the
       prefixed events and naturally, arbitrary events too.

       You do not need to supply events with the prefix in front of them, just the names.

       It is possible to register for all events by specifying 'all' as an event.

       Returns 1 if all the event name[s] was unregistered, undef if some was not found.

INPUT EVENTS

       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"

       Inherited from POE::Component::Syndicator

       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.

       "unregister"

       Inherited from POE::Component::Syndicator

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

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

       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.
       Not supported by all servers.

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

       Talks to NickServ, on networks which have it. 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 IRC::Utils if you would like to use formatting and color
       codes in your messages.

        $irc->yield('primvsg', '#mychannel', 'Hello there');

        # same, but with a green Hello
        use IRC::Utils qw(GREEN NORMAL);
        $irc->yield('primvsg', '#mychannel', GREEN.'Hello'.NORMAL.' there');

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

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

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

       Inherited from POE::Component::Syndicator

       Sent once to the requesting session on registration (see "register"). "ARG0" is a
       reference tothe component's object.

       "irc_shutdown"

       Inherited from POE::Component::Syndicator

       Sent to all registered sessions when the component has been asked to "shutdown". "ARG0"
       will be the session ID of the requesting session.

       "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", which 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", which 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 user's actual ip address, that'll be here;

       ·   'identified'. if the user has identified with NICKSERV (ircu, seven, Plexus)

       ·   'modes', a string describing the user's modes (Rizon)

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

       "irc_plugin_add"

       Inherited from Object::Pluggable

       Emitted whenever a new plugin is added to the pipeline. "ARG0" is the plugin alias. "ARG1"
       is the plugin object.

       "irc_plugin_del"

       Inherited from Object::Pluggable

       Emitted whenever a plugin is removed from the pipeline. "ARG0" is the plugin alias. "ARG1"
       is the plugin object.

       "irc_plugin_error"

       Inherited from Object::Pluggable

       Emitted when an error occurs while executing a plugin handler. "ARG0" is the error
       message. "ARG1" is the plugin alias. "ARG2" is the plugin object.

   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. Usually sent during to you during
       an authentication phase right after you connect, while the server does a hostname lookup
       or similar tasks. "ARG0" is the text of the server's message. "ARG1" is the target, which
       could be '*' or 'AUTH' or whatever. Servers vary as to whether these notices include a
       server name as the sender, or no sender at all. "ARG1" is the sender, if any.

       "irc_delay_set"

       Inherited from POE::Component::Syndicator

       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"

       Inherited from POE::Component::Syndicator

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

   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"
       Inherited from POE::Component::Syndicator

       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"
       Inherited from POE::Component::Syndicator

       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

       This can be an issue. Take a look at IRC::Utils' section on it.

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>

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

MAINTAINERS

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

       Hinrik Örn Sigurðsson <hinrik.sig@gmail.com>

AUTHOR

       Dennis Taylor.

LICENCE

       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.

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.

       IP functions are shamelessly 'borrowed' from Net::IP by Manuel Valente

       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.