NAME

Bot::Cobalt::Core - Bot::Cobalt core and event syndicator

DESCRIPTION

This module is the core of Bot::Cobalt, tying an event syndicator (via POE::Component::Syndicator and Object::Pluggable) into a Log::Handler instance, configuration manager, and other useful tools.

Core is a singleton; within a running Cobalt instance, you can always retrieve the Core via the instance method:

require Bot::Cobalt::Core;
my $core = Bot::Cobalt::Core->instance;

You can also query to find out if Core has been properly instanced:

if ( Bot::Cobalt::Core->is_instanced ) {

}

If you 'use Bot::Cobalt;' you can also access the Core singleton instance via the core() exported sugar:

use Bot::Cobalt;
core->log->info("I'm here now!")

See Bot::Cobalt::Core::Sugar for details.

Public methods are documented in "Core methods" in Bot::Cobalt::Manual::Plugins and the classes & roles listed below.

See:

Custom frontends

It's actually possible to write custom frontends to spawn a Cobalt instance; Bot::Cobalt::Core just needs to be initialized with a valid configuration hash and spawned via POE::Kernel's run() method.

A configuration hash is typically created by Bot::Cobalt::Conf:

my $cconf = Bot::Cobalt::Conf->new(
  etc => $path_to_etc_dir,
);
my $cfg_hash = $cconf->read_cfg;

. . . then passed to Bot::Cobalt::Core before the POE kernel is started:

## Instance a Bot::Cobalt::Core singleton
## Further instance() calls will return the singleton
Bot::Cobalt::Core->instace(
  cfg => $cfg_hash,
  var => $path_to_var_dir,
  
  ## See perldoc Log::Handler regarding log levels:
  loglevel => $loglevel,
  
  ## Debug levels:
  debug => $debug,
  
  ## Indicate whether or not we're forked to the background:
  detached => $detached,
)->init;

Frontends have to worry about fork()/exec() on their own.

AUTHOR

Jon Portnoy <avenj@cobaltirc.org>

http://www.cobaltirc.org