Plans for rbot 1.x

This page collects ideas and proposal for the way rbot should be (re)structured for the 1.x releases. Add proposal and remarks.

Bot is a Singleton

Does it make any sense at all to not have the bot as a singleton? The only case in which it would not make sense is if one considers running multiple bots in the same Ruby session. Why would you do that? (It's broken anyway presently because Utils and Plugin and Auth Managers are Singletons too.

• get rid of all the bot_associate and related methos
• no need to pass around the @bot instance

Multiserver

Bot should be able to connect to multiple servers (actually, multiple networks), optionally with the ability to act as linkbot. All plugins and data handling should stop assuming that there is a single server the bot is connected to

Multiprotocol

Should the bot be able to abstract different protocols? (IRC, Jabber, etc)? It could abstract the procotols providing the same kind of interface (lowest common denominator?) to all of them.

New permanent data storage framework/paradigm

New database

Drop Berkeley DB in favour of an ACID database. Try to keep it simple to install and use, so best candidate is SQLite. This should give us both more robustness and more flexibility.

New data structure

Data is stored in a single db table with column

network

channel

user

plugin

key

value

where any field can be the empty string meaning 'all'. Data retrieval should load the most specific data present (define exact specificity rules, should be a total ordering on all the fields).

Question: do we want an additional field for the bot user as opposed to the IRC user? Or do we use the user field with special syntax such as bot:username vs irc:hostmask ?

Question: value field: Marshall or YAML? (YAML probably, plain text over binary is preferrable). Store strings or integers whenever possible.

Interface

Plugins would have methods such as get_data(key, opts={}), set_data(key, val, opts={}), with_data(key, opts={}, &block). The most important keys in the options Hash are the context selectors: :network, :channel, :user, :plugin, with sane defaults (e.g. :plugin => self). Objects such as IRC messages should provide their own context, so that :context => someobject should initialize the values from someobject.data_context if someobject.respond_to? :data_context

Maybe: provide a DataContext? mixin. This one should provide data_context and get|set|with_data. It should be possible to merge objects that include DataContext?. Provide a merge_context method, and a merge alias unless the class already provides merge. Is it possible to provide both a DataContext? class and a mixin? Use different names?

Configuration

Bot configuration keys should follow the same guidelines as other data structures, so that we have global options, but also optional network overrides and channel overrides and user overrides. How and where do we store these? Global should probably still be kept in a text file (keep conf.yaml?). jsn suggests that network confs should be kept in text files too: makes sense, it comes handy if something causes the bot to not connect to any network anymore. Keep everything in conf.yaml, or have conf.network (or network.yaml?) for network-specific settings?

Channel and user overrides may be stored in the db, get_config(key, opts={}) (with syntax similar to get_data would take care of everything.