Chump rewrite requirements

History

Rev 1.0, 06 September 2007, John Quigley: page created
Rev 1.1, 09 September 2007, John Quigley: organized requirements based on components

1 Preface
2 Scope of this document
3 Codename
4 Language
5 Requirements
6 Developers
7 Tools
8 See Also

Preface

This document details the initial design requirements for the Chump rewrite.

Scope of this document

Since we were talking about chump interacting with the front page and possibly more, how far should this document go describing what the new chump will do?

Codename

There's already several options for a codename for the new chump. The proposals so far are:

chumpr
Sucker (suckr?)
Mark
Rube (on Rails?)
iChump
Chumscrubber
Chimp
patsy

Language

As per our Programming Tonight planning meeting, we'll be writing this in Python. This decision was based on the fact that there are several non-trivial components already written by ourselves in Python which should be integrated (namedly, chump-search and chump-rss), in addition to the fact that the language seems to be the lingua franca amongst our members. Complaints or suggestions, please raise them before it's too late!

Requirements

Description

(This is not requirements per se, but a general description of what is desired. Anything here that must be implemented must be defined explicitly in requirements.)

Core functionality: At it's core, chump is a data repository. It should collect data given to it and record it. Generally this data will be a link, but it could also just be a string of text. It should have a plugin system that provides input interfaces (irc, http, im?) and output interfaces (rss, html, im?). The basic functionality would be to simply list the data that it is given chronologically. It should do this on a rolling basis instead of in 24 hour segments as it does currently. Also, it should allow a user to undo an action that was accidentally performed. Users should be able to apply arbitrary tags to data items for organization, and for marking items for further action by plugins.

Plugins: There should be a well defined api in the chump core that allows complete access to the data. As much functionality as possible should be taken out of the core and put into plugins for maximum adaptability and expandability. Plugins should be able to register a list of tags with the core, and any items that are tagged with registered tags will be sent to the corresponding plugin. Plugins should be able to register their own data stores with the core to store their own data. (should all the data stay in the main repository, or should data that meant to be parsed by a plugin be taken out and kept in the plugin's repository?)

Initial plugins needed:

IRC interface

details

Web interface

submit BLURB and link entries and add comments

rss output

details

Architectural

data storage as XML
component intercommunication strictly XML-based
two distinct entities, the bot and the data store, linked via web api

Web data store and front-end

RESTful web interface for profile management and link moderation

Chump IRC bot

Allow posting meeting information to website, i.e. date, location, presentations
Allow adding events to our google calendar, this can be done with the python google api
configurable plain/ssl sockets
Create facebook events from chump is possible through facebook api
The ability to undo any action done in Chump
RESTful web api for interfacing the bot with the front end
ability to associate irc nicks with chicagolug.org ldap usernames (if the user so desires)

Other Desired Features

(I thought it would be good to just have a place we could drop other things we want to see in Chump at some point. Some of these may move to requirements, some may become plugins or new features later, depending on the nature of the suggestion)

"This was already posted today"

Developers

We're (roughly) going to need people for the following aspects:

javascript design/impl
web user interface design/impl
IRC messaging handlers impl
web RESTful handlers impl
web RESTful API design/impl
XML facilities (IPC and datastore) design/impl

If you are interested in helping the development effort in some way, put your name below along with the corresponding number that you'd like to work on. Note that we can have multiple people working on the same item.

John Quigley: 4, 5, 6. I'll definitly need to work on 4 and 5 at least, since I'm building the web front-end and data store on top of the feedmasher platform that was written by myself. Otherwise, I'm happy to work on anything else in addition to these. I need to learn Javascript, so it would be cool if I could work on this with somebody who has experience in these things.