Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a brain #7

Open
3 tasks
jwilm opened this issue May 28, 2015 · 5 comments
Open
3 tasks

Add a brain #7

jwilm opened this issue May 28, 2015 · 5 comments
Labels

Comments

@jwilm
Copy link
Owner

jwilm commented May 28, 2015

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.

@jwilm jwilm added the A-core label May 28, 2015
This was referenced May 28, 2015
@morganhein
Copy link

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
Copy link
Owner Author

jwilm commented May 28, 2015

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
Copy link
Owner Author

jwilm commented Jun 10, 2015

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
Copy link

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
Copy link
Owner Author

jwilm commented Sep 3, 2015

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! 🎈 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants