Skip to content
This repository has been archived by the owner on Jul 17, 2020. It is now read-only.

Roadmap

Jump to bottom
Zirak edited this page Oct 15, 2013 · 1 revision

Of course, one of the main (if not THE main) priority is clearing up the issue list. Some of these will appear in this list as well. I've classified issues into two: Outwards, referring to how the bot handles human interaction, and Innards, how the bot handles data internally. They're not listed in any particular order - just as they came to me. Like old drunken hobos. They call me Alice. Who the fuck is Alice?

Outwards

  1. Make the bot's responses more human-like and diverse. "Successfully added command foo" is too 1960s robot. We're making a human interface - "Ok, added command foo" is something you can tell your co-worker. Also, make jokes.

  2. Add message editing. This is a pretty big change internally, it'll be discussed in more detail later on in the list.

  3. Handle bot-spam. Most of it is handled in point #2, but make it harder to spam the room via the bot - add flood control.

Innards

  1. Currently, the input event system is weird. We get raw input from bot.adapter, which is then delivered to IO, then to the bot. Commands/listeners get the abstraction of bot.Message, but if you register to IO's input event, you'll get the raw data. That may be fine by itself, however, we have no way of implicitly getting the abstraction without being a command/listener.

  2. ...and the output system is text-based, which is wrong. Commands and listeners return strings, bot.adapter.out operates on just a room and text. We lose a lot of data in here - notably which message we responded to. Besides, if we want to pipe one input through several commands, we have to do weird dances and rituals.

  3. The commands have mixed logic and display. A command's main function has both data handling and output handling in one. Coupled with #2, this means that one command wanting to use another has to jump through extra loops. This sucks. A better system would be composing commands out of two parts: One which handles data (getting it from an external resource, whatever), and one which takes that data, and formats the output. We can then make a wrapper function, the actual command the bot calls, which pipes the output of the former to the latter.

  4. bot is a bit of a god object. It's mitigated by some sub-organising (bot.memory, bot.adapter, etc), but it has over 30 properties and methods. It might not be a real issue, but it should be looked into. Or not. Either way, pancakes. Lots and lots of pancakes.

  5. Of course, cleaning and refactoring bits and pieces of the bot is always good, conforming to the style guide whatever you do, fixing places where it doesn't (whoopsies).

  6. node. Moving the bot to a server, away from the browser. This'll be huge, and should probably be done in steps (only make the logic first, have the chat interaction be in the browser, establish socket communication between the two) until we're comfortable.

Clone this wiki locally