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

Handle extra config properties provided by third-party plugins #1012

Open
JustArchi opened this issue Jun 24, 2020 · 7 comments
Open

Handle extra config properties provided by third-party plugins #1012

JustArchi opened this issue Jun 24, 2020 · 7 comments
Assignees
Labels
✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request. 🙏 Wishlist Issues marked with this label are wishlisted. We'd like to make them happen but they're not crucial.

Comments

@JustArchi
Copy link
Member

Purpose

ASF-ui should be aware of extra properties that are provided by third-party plugins, "added" to the bot and global configs, without existing in ASF's structure.

Solution

Up to discussion, for now I'm thinking of ASF API that could ask all currently loaded plugins to provide a map of ConfigType (ASF or Bot) and Class reference of the structure that it appends to the config. Then ASF-ui could read that and present user "extended" view as union of all of those.

Alternatives

I'm open for other ideas.

Additional information

This will be needed if ASF-ui wants to handle SteamTokenDumperPluginEnabled as described on https://github.com/JustArchiNET/ArchiSteamFarm/wiki/SteamTokenDumperPlugin

@JustArchi JustArchi added the 🧐 Evaluation Issues marked with this label are currently being evaluated if they're going to be considered. label Jun 24, 2020
@JustArchi
Copy link
Member Author

Initial idea of ASF API response:

Two Dictionary<string, Type> fields from each plugin, one for ASF config and one for Bot config. Each entry in a dictionary would be name of the property and Type the property expects. Type will be exactly the same like in existing /Type API endpoint, so System.Boolean etc.

@MrBurrBurr
Copy link
Member

MrBurrBurr commented Jun 24, 2020

I also wanted to add a new view where every plugin is listed (i think abry suggested this on disc).

Maybe we should add those config properties there? Not sure if we want to extend default global config view. Or maybe that would be problematic since plugins can also add config properties for bots. Hm... I am sure you and Mole will think about it and come up with the best solution.

@MrBurrBurr MrBurrBurr added ✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 🗫 Feedback welcome Issues marked with this label are open to any potential feedback that could help us. 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request. 🟡 Medium priority Issues marked with this label have a priority, unless there is something even more important. and removed 🧐 Evaluation Issues marked with this label are currently being evaluated if they're going to be considered. labels Jun 24, 2020
@JustArchi
Copy link
Member Author

Good idea actually, there can be plugins view and in that view, optionally, each plugin can list its additional dependencies, like extra config properties. Much more robust than just dedicated view for config properties.

I'll start working on it and let you know once there is something you can code logic for.

@MrBurrBurr
Copy link
Member

Can plugins extend bot config? If yes then we have to think about how we gonna handle that in the new plugin view.

@MrBurrBurr MrBurrBurr changed the title ASF-ui should handle extra config properties provided by third-party plugins Handle extra config properties provided by third-party plugins Jun 24, 2020
@MrBurrBurr MrBurrBurr assigned MrBurrBurr and unassigned MrBurrBurr Jun 24, 2020
@Abrynos
Copy link
Contributor

Abrynos commented Jun 24, 2020

i think abry suggested this on disc

yes. I did suggest that. The reason why I haven't already made a PR for this is, that I wanted to combine it with providing extra config properties to ASF-ui as well and I didn't have the time to think about the way to do it yet.

Can plugins extend bot config?

Yes. Plugins receive all additional configuration values when bot config is loaded. My thought would be to add a "section" (maybe use <hr> or something similar) below normal bot configuration properties for each plugin.

@JustArchi
Copy link
Member Author

Our latest discussion with @Aareksio resulted in a bit different approach:

Instead of any additional API endpoint, plugins can tag schemas in swagger.json, and ASF-ui will know that it needs to merge those with the main configs.

@JustArchi
Copy link
Member Author

JustArchi commented Jun 24, 2020

(API endpoint for discovering currently-loaded plugins is still a fine idea, but something entirely different than what we're doing in this issue, and that one indeed needs a standalone API endpoint)

@MrBurrBurr MrBurrBurr removed the 🗫 Feedback welcome Issues marked with this label are open to any potential feedback that could help us. label Jul 19, 2020
@MrBurrBurr MrBurrBurr added the 🙏 Wishlist Issues marked with this label are wishlisted. We'd like to make them happen but they're not crucial. label Aug 26, 2020
@MrBurrBurr MrBurrBurr added Priority: None and removed 🟡 Medium priority Issues marked with this label have a priority, unless there is something even more important. Priority: None labels Jan 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request. 🙏 Wishlist Issues marked with this label are wishlisted. We'd like to make them happen but they're not crucial.
Projects
None yet
Development

No branches or pull requests

4 participants