Add a brain

[jwilm]

Make it so the bot can remember things. Create a brain that the handlers and adapters can use.

• [ ] Add a Brain trait
• [ ] Add a RedisBrain implementation
• [ ] maybe: Add a text file implementation

Is there any value in the text file version? It might be nice for debugging. I would worry about losing data.

[morganhein]

I can't personally see a reason to use a flatfile, but I could see using another nosql db style like Mongo being useful. I've not much knowledge on Redis, but i'm looking at possibly creating a "smart" ai, and have no clue of the data structure required to do so;

My point is that creating a solid interface/trait for db access is more important than a flatfile; which would allow implementations for whatever backend we might want.

[jwilm]

The initial trait I had in mind was something like:

trait Brain {
    fn set(key: &str, value: Json);
    fn get(key: &str) -> Json
}

Since that would support all of the adapter/handler usage I have conceived so far.

[jwilm]

I'm torn between having a generic persistence trait like above and just offering a namespaced Redis wrapper to the handlers. The trade is as follows.

Generic

• Simple interface which could be implemented for a number of persistence layers including sqlite, redis, or just a Fs wrapper
• The trait proposed above forces the handlers to work with Json objects which may not be desirable

Redis

• Full power of redis (access to all commands). This could make a certain class of handlers far easier to implement
• Requires Redis server

Hubot went the route of having a brain which is just a JSON keystore thing. Lita went the latter route and offered the full redis API. One of hubot's more popular plugins is a redis-brain, but it's really just a JSON key store backed by redis.

I'm inclined to go the Redis route because it's definitely more flexible from the handler perspective.

[bhechinger]

Do both! :-D

Seriously though, I'd say go the Redis route. There's really no compelling reason to use something other than Redis for a keystore. It does it very well after all.

[jwilm]

Thanks for the feedback! I have been thinking similarly. In addition to the value of the keystore, several of the handlers I want to build would benefit from the set functions. Sadly I haven't made time to work on this for a while... but there is a long weekend coming up! :balloon: :grin: