I’m working, slowly, on an OH2.0 Insteon binding. Yay! The OH1 binding was written by Bernd Pfrommer to use a lot of data-driven constructs, such as the list of known Insteon devices, and the features those devices offer. It is very nicely done, and he did an excellent job of keeping the logic and interface separate. Much of the code to handle the complex Insteon protocol ports very cleanly.
Being an OH1 binding, the current insteonplm knows nothing about Things. It maps items directly to channels. To be an effective OH2 binding, insteonplm needs to define the Things that the PLM bridge can connect to.
The V2 binding needs to define all the items in that XML file as Thing types. I see several ways to do this:
1> When the binding loads, read the XML and insert new thing types into the system to match the items in the XML file. Possibly remove the thing types when the binding unloads.
2> Use a tool at build time to read the XML file and write new static XML files for the thing definitions. OH will manage those things via the normal XML methods.
3> Maintain the Thing definition XML files independently of the Insteon definition XML files.
Right now, the Insteon definition XML files are stored in the jar file, and updating them is technically possible without a new release of the code, but normally this would be done by releasing a new version of the jar file built with the new XML files. If the XML files were stored externally, and easily replaced or updated without rebuilding the jar file, I would be leaning heavily towards option #1 so that the XML could be updated by the end user. However, the files are stored in the jar, and most users won’t feel comfortable manually updating the contents of the jar file.
Option 2 seems plausible to me, but I have no idea how to get OH’s build tools to automate it. Were this standard Makefiles, I would jump on this in a moment, but Maven is a scary unknown to me, and I’m already sinking in the learning curve.
Frankly, I’m probably going to start with Option 3, so I can keep moving. Either of options 1 or 2 can be added later to make maintenance and updates easier. Option 3 lets me write some XML and have things to put in the system to begin testing with, and lets me manually play with the ideas of how the Insteon feature definition file maps to things and channels.
Other binding developers: Which do you think makes the most sense?
Binding users: Do you care, as long as it works?
Anyone have any thoughts?