-
-
Save Supinic/6a634b1bb94d3a3441653179cb873164 to your computer and use it in GitHub Desktop.
1. Repo will be new, and separate from anything that concerns the `supibot-sql` repo | |
- (idea: supibot-sql is just a version control for whatever the main instance does) | |
2. Implement a method into `sb.Command` to "install" a new command from a description object | |
3. sb.Command.install will also handle duplicates - will update instead of failing (like now) | |
4. Repo command definitions will be in `.js` syntax as IIFEs that return a description object | |
5. Each command definition should be prefaced by an author/ownership comment | |
6. Think about some sort of authorship/source signature hash, not necessarily as a part of the definitiion but rather as a separate file or a list of hashsums in the root dir |
sb.Command.install
will also handle duplicates - will update instead of failing (like now)
IMO this should be a flag to not accidentally override a command.
each command could also have the source it was downloaded from in the table, making it easy to group
the problem I have with this is the data type, or rather uniqueness of the table's column values
let's say commands have sources Alice
and Bob
, would the Source
column be a unique VARCHAR
? or an ENUM
?
ENUM
seems to be out of question since we don't want to force people to update their tables on the go
a unique column would work alright I suppose
I would think of the source as the Github repository (username/repo_name
) or even path to the command (username/repo_name/commands/command.js
).
sb.Command.install
will also handle duplicates - will update instead of failing (like now)IMO this should be a flag to not accidentally override a command.
the best approach would imo probably to have flags for both
installable
commands (to separate commands that should not be installed remotely)overwritable
commands (which along with theinstall
flag would update themselves as needed)
I would think of the source as the Github repository (
username/repo_name
) or even path to the command (username/repo_name/commands/command.js
).
does this mean there would always have to be two copies of a command? one in the "aggregate" repo and one in each author's repo?
i feel like custom version control repos shouldn't be connected to this repo
each command could also have the source it was downloaded from in the table, making it easy to group