Skip to content

Latest commit

 

History

History
174 lines (128 loc) · 6.04 KB

TODO.org

File metadata and controls

174 lines (128 loc) · 6.04 KB
  • Move METAR utility functions to their own file?
  • CLOS-ize trigger lists
  • Fix the random chain start once and for all
  • Generalize the title/tweet scraping code to permit a variety of URL intercepts and scrapers
  • fetch-file, fetch-source-dir could be rewritten on a template engine
  • factory functions for contexts?
  • unify plugin-request w/irc message class, use throughout
  • add logging
  • Initialize DB schema
  • Work out how config is read: config file applies idempotent inserts to config table, then config table is used to run the bot?
    • contexts finer-grained than per-nick
    • many-to-one IRC:Web context mappings?
    • migrate DB credentials out of context system?
  • Starting an instance with an empty DB should just work.
  • There’s still some ugly bodgery in the mapping from Web server ports to contexts. Build support to incorporate Web server names, names/IPs, base URIs, etc.
  • Write architecture doc
  • Write operator’s manual
  • Write history
  • Start to work up a useful exports list
  • Figure a way to patch http-request in place, drop http-request.lisp
  • Improve the source code lister: line numbers, maybe internal symbol indexing
  • Logarithmic probabilities in chainer
  • Coalesce entries in chain DB
  • Follow nick changes. Should the ignore list be a flag on cl-irc’s user class? A: Yes. Done.
  • More robust checking for own URLs in shortener logic. (Scanning for 127.0.0.1 is fragile.)
  • Do full RFC 2616 comparisons of URLs in the shortener
    • scheme name, host name are case-insensitive
    • empty path == “/”
    • do lookups on raw IP addrs?
  • Smart rejoin. Detect disconnects from server.
  • Is it worth exploring the Google Calc JSON API?
  • Figure a more elegant way to write the defplugin macro
  • add config option for non-babbling bot instances
  • paste bin
  • user profiles/auth
    • two levels: easy, depending on host/ident, and hard, using dcc/https
  • enable plugins selectively on a contextual basis
  • create a REPL context for testing
    • also make it easier to run other contexts from the REPL
  • Pre-reserve short URL hashes corresponding to Web service names
  • Harden the /source service against fetching forbidden or nonexistent files.

BUG: Why does the en dash in the title of http://www.vulva-original.com/home-en.htm not get correctly decoded from UTF-8?

  • Add smarter indexing for URLs
  • Make the context subsystem (and other parts, generally) recover more gracefully when errors attack
    • In particular, if there are no contexts, no words in context, or no urls in context, a report would be in order, not a freeze.
  • Count plugin usage to see what’s popular?
  • Calendars, reminders within the bot
    • Hook into Google Calendar/iCal/other services for same
  • Get full host string w/Web request
  • !conv: detect failed return?
  • Limit length of title strings
  • Paginate full-page URL listing
  • Smarter chaining: punctuation, better endings
  • Do some unit conversion locally
  • Make short URLs longer when table > high water mark
  • Test that short URLs won’t collide
  • Implement transactions in DB
  • Read Web pages for chaining data
  • Shorter domain name w/out port #
    • Now that we’re in production, maybe this takes a back seat.
  • Auth module
  • Twitter plug-in, SMS gateway
  • More back-end Web stuff

BUGS

  • The timers are still wedging.
  • !conv fails on weird utf-8 inputs [Found by Kritter]
  • Should https:// links be shortened? [Found by Kritter, Fade]
  • http://www.phat.uklinux.net/cgi-bin/crash.cgi doesn’t generate a return [Found by Kritter]

Issues irc-client.lisp:start-ignoring

  • Replace the test somehow and push with pushnew?

Why’s the assignment to clhs-lookup::*hyperspec-root* in fetch-file not always going through as it should?

Every use of flexi-streams is going to need wrapped with that substitution-char bullshit.

Apparently the METAR data handed out by NOAA is garbage.

When someone re-pastes a URL into a different channel, it doesn’t get added to the new context. Should it?

Personal Profiles

We’ll allow IRC users to associate a nick with a personal profile. The profile can include things like which weather station to use for the !metar plugin, stock symbols to track, a preferred greeting when the bot sees you’re active, etc.

We already have one featurelet that’s sort of like a personal profile; the !ignoreme function.

Authentication

We’ll need a way to associate an IRC nick with a profile. We can use a DCC message and/or a Web-based auth system.

As a first step, allow “weak” authentication in the form of just assuming that a nick owns a profile. That’ll let us build the system up a bit before we worry about hard security.

Nick Tracking

Right now, every time the bot sees a message (public or private) from a user, it’s a separate event. There’s no effort made to keep track of nicks through nick changes or departures and reappearances.

We’ll need to modify the IRC code to receive messages related to nick changes, departures from channel or from the server, and arrivals. All these events will need to be hooked into the profile system.

Profiles

The user profile itself needs some sort of data structure. When a user asks us to do something, how do we look up a user profile, and how might that profile modify what we do?

We need to work out an in-memory store for profile data, and change the IRC hooks for message handling to use it. This is all rather nebulous, so what we really need is:

A Couple Of Examples

We should implement a handful of things which the bot will do with reference to profiles. Once we see how those work, we can figure out what the common elements are, and cut down a little on the bodgery.

Persistent Storage

Eventually we’re going to need a way to store user profiles in the database. Probably best to just have a direct mapping from the data structure we use in memory to some sort of entry in a table–nothing fancy. When a user authenticates, we can load the profile and keep it in memory.

Getters/Setters

We’re going to need a way for users to retrieve their profile data and a way for them to change it. Again, some combination of web and IRC methods is probably going to be needed.