dylanj / irc-cpp Goto Github PK

Netcode must be written to use the configured server values to resolve hostnames, and connect via tcp to the desired irc server. The server should be able to be connected to and disconnected from with single calls into the netcode irc server object.

Parsing privmsg and notice events are for stiffs. The modules should provide a way for a developer to register a command with the bot. A command is different than parsing a privmsg/notice in that there's less work involved for the developer. Typically commands for bots are in the form:

<prefix><command> <command arguments>...

By eliminating having to manually parse the prefix and the command name, we can allow more streamlined module development. The code that implements "commands" will use a bot-wide configured prefix, and parse these registered commands and send the arguments to the modules event handler. This is a mini eventing system in it's own right.

All input/output from the bot should be kept in one place. An abstracted logging system should be built. This system should output to any stream given to it.

The configuration errors should be logged to the bot's logging facilities. These errors are not simple validation but logical errors that would prevent the bot from working correctly such as: A server's send buffer should not be 1 byte wide.

The configuration file must be read and parsed into an accessible singleton to allow all bot components to read from the configuration.

SSL connections to IRC server should be supported.

There should be some facility to "identify" a user. This identification must be very rigorous and secure as it could create holes in the bot's ability to serve clients with powerful access control based modules.

Typically this is done by some manner of hostmask as nickname isn't a solid identifier of identity on some irc networks.

An attempt could be made by parsing whois data to obtain additional network related information and base some or all identification on that perhaps.

The bot must be able to use a public interface into the bot's netcode to send and receive data. This data should be split on \r\n according to the RFC and should not present these extraneous characters to the bot's calling functions.

The channel system must be able to provide information about a channel. Topic, users, modes, bans.

The channel database should be able to store persisting information about channels. It should be abstracted to the point that a: FileChannelDB or MysqlChannelDB could be inserted at any moment. Allowing for freedom of storage engine.

Default configuration values should be hardcoded to allow fallback when the entities are not present in the configuration file.

The user database should be able to store persisting information about users. It should be abstracted to the point that a: FileUserDB or MysqlUserDB could be inserted at any moment. Allowing for freedom of storage engine.

Modules should be able to be collapsed. This entails removing all events registered by the module, and collapsing it's address space. However that's going to be done.

The configuration should support perform commands. These commands could be IRC raw or some sort of DSL specific to the config file that limits the abilities of the perform section of the configuration.

The modules should be able to register events and have their event handlers called when irc protocol events are parsed by the eventing system.

Modules should be able to be loaded. This entails bringing the module into memory space, and executing an initialization function that will probably pass something in to allow event registration.

Channels should be able to be configured to autojoin on server connect.

There should be some form of intelligent output buffering for the bot. A call into the write function should 'queue' the data for sending. The queue should be consumed in a manner than does not allow the bot to flood off a network.

Modules should have their configuration data stored inside the global configuration system to avoid having multiple places to configure the bot.

IRC Protocol events must be created. Either a system to create them, or some hardcoded transference of the rfc document to enable these events to be registered to.

Users should be able to create their own configuration options for certain modules. Since this is likely to be a common thing the bot should assume that modules will want to do this and allow users to store configuration per module (maybe per server per module?).

All IRC messages must map to either an event, or should trigger the raw handler. It may be desirable to do both.

Some global access level should be available to users. Whether in the form of flags or numerical or both. This should allow modules to query this information in some fashion.

The user system should be able to provide information about a user, since the last time they were recognized, their current server and channel whereabouts etc.

The configuration file in whatever format must be validated to ensure correctness of all entities and inclusion of required entities.

Events must be able to have callbacks registered to them. So if an IRC Protocol comes in saying: :someuser NOTICE BotName :Hello, the notice event must be fired to allow for modules and the bot's core to handle the event.

Linked list implementation will be important for the bot.

Servers should be able to have addresses, ports, active modules, channels.

A hash table will be important for the core.