@rlkoshak: I’d love to get additional feedback from you on these (constructive!) criticisms. You’re a definite (spiritual, if not official ) leader in the community.
I know UI rules are supported now, and have been for some time. They’re probably not the primary method that any of the people that maintain the JRuby/OpenHAB libraries use, but we’re at least aware of them. So let’s assume that’s no longer an issue…
Next up … inter-rule caching. I assume you’re referring mainly to UI rules, no? Because if you’re writing file-based rules, it’s excessively simple to just have a variable (there are several types in Ruby) that lives at the top level outside of any particular rule, just like you would in DSL. There’s not currently a way to access a global variable between files, because each file gets its own instance of JRuby (unless you tweak some configuration that the add-on at least lets you tweak, but hasn’t really been tested to work well that way). Okay, so back to UI rules - wouldn’t all languages have the same problem? It seems that Add an access-tracking cache to be used in rules by J-N-K · Pull Request #2887 · openhab/openhab-core · GitHub is really what we need, and it’s still pending. As soon as it’s in, I’d be happy to quickly add idiomatic support to it for the JRuby libraries. If you really think this is a major obstacle to adoption of people using JRuby actions, I could even jump in and try to get the core PR through. I’ve been gaining some experience in core and a couple of other addons lately too, so I’m feeling like I could get to that.
And finally… documentation. I totally hear you here. For the past month or two I’ve been working on major refactoring of the JRuby scripting libraries, and part of that was motivated by dissatisfaction with the documentation (both using it, and writing it). You can see the new docs for my release candidate at File: README — Documentation by YARD 0.9.28. It’s now strictly in the primary code-documentation tool for Ruby (YARD), so the class, method, and parameter details etc. are guaranteed to be up to date with the library’s actual code, and the examples are now inline so you don’t have to jump back and forth between example and narrative documentation to the technical documentation. It is still not on Introduction | openHAB, but given that the library evolves on a very different schedule from openHAB itself, I don’t think that’s necessarily a bad thing – and wouldn’t really be possible I don’t think, given how it’s generated via YARD. We could definitely improve the theming to look more like the official documentation site. So, given that, would a link to this documentation from the add-on’s README and main configuration page in openHAB proper improve the discoverability enough?
Oh, and one more thing. Would you recommend that we try to get the gem’s repository moved into the openHAB org on GitHub, instead of hosted on our own personal account? It doesn’t really matter to me where it is, as long as we can continue to maintain it ourselves. But it would give even more air of endorsement of “this is how you use Ruby in openHAB”. And the docs could move to https://openhab.github.io/openhab-jrubyscripting/ - a slightly better URL.
Let me know your thoughts, I definitely want to appeal to as broad of an audience of openHAB users as possible.