search

the-round-table / trtbot

🤖 Discord Bot
MIT License
3 stars 0 forks source link

Add the ability to enable/disable listeners in-bot #54

Open bcongdon opened 5 years ago

bcongdon commented 5 years ago

Settings should be managed per-guild

narendasan commented 5 years ago

There shouldnt be a bot that spans guilds though right? What does it look like for someone to use the bot? in my head its like npm install bot (cant remember the name) and maybe some CLI to select features we already built then you get a setup project where you fill out the config with the necessary tokens and and run npm start and you have a working project. Then there can be a directory or something for custom work to be placed.

narendasan commented 5 years ago

Or is it like we host this one bot for any guild to use this single instance with settings and data partitioned? IMO, I think this should be a framework for building custom features quickly vs. a bot with a lot of features

bcongdon commented 5 years ago

Most discord bots are like a single monolithic instance that services many guilds. I'm not sure if we want to do that, but I think it still makes sense to have settings managed per guild. That way, if you as a operator of the bot want it to span multiple guilds, you have that support

narendasan commented 5 years ago

hmm, yeah i mean i know most servers just add a bunch of different bots to do things, thats why i think the custom use case is the most interesting. I think just like us we are going to find that a lot of people would want to support specific things and just need an easy way to build them/have a wide library to pull in and customize. i think that its def something to have support for, but imo more later in the roadmap

Joshuad2uiuc commented 5 years ago

Is the best way to do it just to have a config file that you can specify when installing the bot on a guild and also like maybe the owners of the guild or something can dm the bot with config changes or something?

narendasan commented 5 years ago

I like the notion of a config file, almost a package.json for the bot (but toml or yaml pls :smile:) I think the only real drawback is now your are mutating files on disk to support in discord admin, which is not great since you can either cache settings and try to keep the two in sync (you can do it but basically we would need to create and api that manages the config to make changes to the config file and cache happen atomicly and know when to flush the cache - prob on boot only really) or resolve to reading the config file for everything.

Joshuad2uiuc commented 5 years ago

Bad idea possibly, but just setting boolean flags in the code ? I am not sure if the tradeoff is worth instead of writing to disk etc.

bcongdon commented 5 years ago

Asking users to change code for a settings is an anti-pattern imo. Naren's YAML config example seems more reasonable

Joshuad2uiuc commented 5 years ago

Antipatterns are the new patterns lol. but yeah Naren just posed some issues with config file after I said and did not know if doing a config file would be too slow or something.

narendasan commented 5 years ago

I think the best solution might be a configuration manager to be the source of truth in the application and decides when to trust the config file and when to flush its internal config to the config file. The nice thing is you need to only really need to load the file at the beginning and flush the diff to file on shutdown (might be a bit harder)

bcongdon commented 5 years ago

fwiw Commando has a sqlite settings provider that we can use -- it's basically a key-value store backed by sqlite https://discord.js.org/#/docs/commando/master/class/CommandoClient?scrollTo=settings

narendasan commented 5 years ago

I guess if you can load from file into that, thats a good option i think