I’m not sure of the level of effort, but the introduction of GraalVM would be a significant change that I expect would have to go into a major release. I do not know yet if it is something that is technically feasible or would be approved, but it’s about time to create an issue to start the discussion. Like javax.script, GraalVM can be used for much more than automation, so the discussion could take a while. From what I’ve picked up, it sounds like we will go from 2.5 to 3.0, which would leave very little time for it, and there is already a lot of work to do within automation before then.
I know what ECMAScript means. Dynamic reading is already best! There are many, many more important things!
The integration would not mean that all other facets that GraalVM can offer have to be done at the same time. It would also correct the later conversion to Java 11/12, if JSR223 has to be replaced.
Of course, it would only make sense if GraalVM could be made usable relatively easily in openHAB 2.5 and few classes would have to be adapted. Thank you for your estimation, you are much deeper in the story.
Maybe we should cut out the graalvm topic from here, since it isn’t that related to the documentation.
I will prepare a little summary at the weekend and then we can have a look at things that could be done/prepared already.
We should definetely think about the generic rule presentation in the docs too, while organizing the jsr223 refactoring.
This is something we have to improve.
We should not say xtend is bad or jsr is better, but we should have a rules area that explains the possibilities and then afterwards shows more information about the different ways of doing rules.
I am also thinking of extracting the rules articles out of the configuration section and moving it into its own docs section.
Rules is such a big topic and you cant explain it with one side per rule techinque.
I agree. I wonder if a hierarchical organization makes sense. We have a root article that talks about what Rules are for and some of that generic stuff that I’ve mentioned above. Then under that we link to separate pages for Rules DSL and each of the JSR223 languages.
That way we privilege none of the languages over the others and it becomes apparent even to newer users that there is more than one option.
I’m ambivalent as to whether we should also mention third party options here. Part of me thinks it would be helpful and part of me thinks it’s not our job.
Currently, there is no Concepts> Rules section. We could make one and put the general discussion and explanation of the differences between the rule engines in there. The Configuration Guide> Rules and JSR223 sections could be combined and use the fancy tabs as in Jerome’s example. IMO we should put emphasis on the new rule engine, with UI first and then put the DSL at the end. After 3.0, the DSL section can be tagged as legacy or moved to another area which includes steps for migrating .rule files. The New User Tutorial> Working with Rules and Script section could focus on working with rules in the UI, as that is what will be easiest for a beginner.
I really like the tabs! In looking at the docs, there is a wall of information that I think the tabs could help organize in a way that it is easier to locate what you are looking for. For example, the sidebar for the Installation Guide could just be Overview, OS and Hardware, with tabs in each section. This is too general for this discussion, but those tabs could really help the docs.
Nothing comes to mind, but thank you! I’m first pushing a Jython update for compatibility after the ESH reintegration package name changes. I’ve made it backwards compatible too, so no breaking changes. I’ve also added in all of the other OH classes, so that no changes should be necessary when the rest of the packages are renamed. This is ready to go, but I’ve been going through every file and it’s hard not to do some housekeeping while I’m in there!
Awesome. I’m having some troubles with the hello_world.py example (specifically it not being parsed because OH doesn’t seem to see the core modules under /lib/python - I get Error during evaluation of script 'file:/openhab/conf/automation/jsr223/personal/hello_world.py': ImportError: No module named core in <script> ) and I’m hoping that this will fix it, or at least rule out it being related to package names.
Before the helper library doc rewrite, I had separated out all of the information that was just about scripted automation or common to all languages. These changes ended up being used in the helper library doc rewrite, but it was lumped back in with everything else. I’d now like to get back to separating this information and submitting the other changes I have for the OH scripted automation docs.