Add a way for JSON-RPC V2 plugins to get settings on initialization/restart

[cibere]

Is your feature request related to a problem? Please describe.

I'm writing a python library that uses the V2 json-rpc api, and it really annoys me that although there is an initialization request that would be perfect for plugins to create a cache, plugins have to wait until the first query request is received to start building their cache, resulting in long first queries. This is because currently, the plugin's settings only seem to be sent to the plugin on query requests.

Describe the solution you'd like

I'd be ok with either of the following solutions:

1. Add a GetSettings method to the public Flow API, so that plugins can request the settings on initialization.
2. Include the current settings to the plugin in the initialize method's parameters (and based on how #Reload Context #3081 gets resolved, making sure its in the restart method's parameters as well)

Describe alternatives you've considered

Having the plugin read the plugin's settings file on restart, but although this would probably work as a "solution", this issue seems like it should have a better fix.

Additional context

Add any other context or screenshots about the feature request here.

[taooceros]

How about we abandon the setting passed via query and completely adopt the request/response model via a GetSetting and SetSetting?

[taooceros]

@Yusyuriv @Garulf what do you think?

[Yusyuriv]

Yeah, I also thought that it's a little awkward. It probably made sense in API v1, when plugin's whole lifecycle was start-respond to query-end, but having GetSettings/SetSettings for v2 sounds useful. I think ideal would be:

1. Pass settings to the initialize method.
2. Keep passing settings to query method.
3. Add GetSettings/SetSettings methods for v2 plugins.
4. Not sure if it would be useful, but maybe allow defining another optional request for v2 plugins, something like settings_updated, so plugins can subscribe to real-time changes to settings?

[Garulf]

@Yusyuriv @Garulf what do you think?

This makes the most sense.

[Yusyuriv]

@Yusyuriv @Garulf what do you think?

This makes the most sense.

I think you quoted the wrong message?

[taooceros]

but would then the GetSetting be a little bit duplicate.

[Yusyuriv]

If you're talking about it being redundant when there are points 1 and 2: I thought that there might be a use case when the user haven't used the plugin for a while, but the plugin needs to update some data for example every 5 minutes. It needs to do so using the current settings that might have changed since the last time the user used the plugin.

If you're talking about point 4, then I agree, GetSettings might be unnecessary here.

[taooceros]

I actually feel like point 4 is quite interesting as a proactor mode. Was a little bit trapped by application lately. I will write some impl after this week.

Or on the other hand if you would like to proceed feel free to do so.

[taooceros]

@Yusyuriv how do you think we make it event driven. When setting is changed by user, we invoke a event, which fires the changed part to the plugin (this can be done directly via the jsonrpc library with a c# event). Still we can implement a getSetting api.

[Yusyuriv]

@Yusyuriv how do you think we make it event driven. When setting is changed by user, we invoke a event, which fires the changed part to the plugin (this can be done directly via the jsonrpc library with a c# event). Still we can implement a getSetting api.

So the event will only send the changed parts, and if you need to get all of the current settings, you'd use GetSettings (for example in initialize)? Sounds good.