Script Providers - Guidance on configurability

[boc-tothefuture]

I have a JRuby ScriptEngine that I am getting ready to submit for review. I had a couple of questions for the maintainers here before I submit to ensure I am following best practices.

For the most part I based it on the very simple Groovy Script Engine, but with some modifications so that it does not break Ruby (don't overwrite the File object for example).

My question is on if we are allowed to add configurations to the Script Providers?
In the JRuby case it would be beneficial to our user base (certainly in the support of helper libraries) to be able to set a couple of optional variables. For ruby this includes a lib path and a gem path at a minimum. I am also considering the ability to specify a set of gems that may be installed to ease in the distribution of helper libraries or access to the ruby ecosystem from within the UI.

All of these would be optional and if not specified then the scripting engine would work as normal.

Is there any issue with providing optional configuration elements in the Script Providers?

Full Disclosure - I haven't looked to see how to provide or process configuration elements for ScriptProviders (I am hoping they are like other bindings)...

[boc-tothefuture]

@kaikreuzer Do you know who could weigh in on this?

[kaikreuzer]

Since the script engines are provided as an "add-ons", I do not see any issue with adding a configuration to it.
Their OSGi service can simply use a pid like org.openhab.automation.jrubyscripting and accept an optional configuration for it. Bindings can currently do the same (but not many do, here is one example).

I just checked and it seems that we aren't yet able to provide this configuration through the UI, so a .cfg file is the only option for now. I wonder if we shouldn't replace the binding.xml file (which currently contains the config desc for bindings, by a general addon.xml, which would then also apply for all other add-on types - wdyt @openhab/core-maintainers?

[ghys]

Chiming in to say this would require an API change since bindings are configured in the /bindings endpoint which also lists them all, whatever their source (distribution, marketplace, sideloaded). It would be a good thing to be able to have the same with other add-on types, as well as an indication of the source, and possibly some versions management as well (list versions from all sources and install a specific one if applicable); only then they could reasonably be integrated in the add-ons settings in the UI which currently doesn't display sideloaded add-ons for example (I received reports about sideloaded bindings not being able to be configured).

[kaikreuzer]

@ghys Yes, I am aware that this would mean a bigger change that will also impact the REST API and the UI and hence needs to be aligned with you - I have created #2058 for further discussion.

the UI which currently doesn't display sideloaded add-ons for example (I received reports about sideloaded bindings not being able to be configured).

Is it at all possible to configure bindings right now? I tried it with the network binding that I mentioned above, but couldn't see any configuration possibilities in the UI for it.

@boc-tothefuture I assume your question is answered, so I'm closing this issue.