I think if you’re setting yourself to believe that the entire catalog of plugins is going to run happily on the replacement firmware, you’re gonna have a bad time.
The engineering realities of that are pretty grim. Let me hit a few highlights:
- eZLO needs to do everything they need to do to advance the firmware, yet still make the legacy API work compatibly. This will inevitably lead to conflicting and irreconcilable requirements, and when they arise, the requirements of the new will win.
- Even if there are no conflicts, the chances of them getting it 100% right are slim, as the existing environment is the product of years of development and countless exceptions, nuances, and featurelets, many of which are likely undocumented except for their subtle manifestation in code. That’s not meant to be a slight on them or their effort, it’s just a reality. The system is so old, and so complex, that the idea that you can reproduce it with 100% compatibility in a new environment in a fraction of time is a fantasy. There will be mistakes made. There will be omissions. There will be unexpected side-effects.
- They are adding data to the system. If the legacy API does not return these new data elements, the plugins may run into scenarios where other actions they perform damage new system structures by removing data, or providing conflicting/incompatible data (unknowingly). It is also possible that the receipt of unexpected data may cause erroneous operation of the plugin, up to and including total failure.
- Unfortunately, many of the plugins in the current catalog and in common use today are… I’ve seen too many that operate more by accident than intent. The very shortcomings that the current environment ignores may not be ignored in the new environment.
- Not unreasonably, once the work is done, eZLO will assert that the result is the new reference specification for the legacy Luup API, and any failure of the plugin to operate on the compatibility API will likely be dismissed as the fault of the plugin (and rightly so). That means the community is still left with a non-working plugin, and in need of a community developer to fix it.
- Any discrepancy that is identified that they do agree to fix will likely require a turn of firmware, so time goes by while you’re waiting to get past that hurdle… so you can move along far enough to find the next one. Lather, rinse, repeat.
- As we all know, not all bugs stand up on day one and announce their presence. Sometimes they come much later (imagine something related to DST changes, seen only twice per year, or worse, only faulting when adjusting backward, so once per year). If everyone is out of the rapid turn cycle of pre-GA, like the previous bullet, new firmware required to fix, but now it’s going to take a lot longer, and in the meanwhile, you’re scr… without a functional plugin.
- It’s not going to stick around forever. The legacy Luup API will be deprecated the day it’s released, so anything that does operate on it is on borrowed time.
In addition, as a developer, I want access to all the best new stuff. So I have no incentive to stay on the old APIs, and not do whatever is needed, rewriting included (and expected), to get access to all the greatest things that this new firmware can offer. Anything else is just buying time, wasting time.
So, while I believe they may produce a compatible API, I think it’s optimistic to the point of being intellectually dishonest that everything is going to work and life will go on uninterrupted. I may be wrong, but I think the odds are far too long the other way.
Edit: we now have, in the API documentation just previewed, sufficient evidence of point #1: the structure of scenes in the new system is vastly complex (too much so, I think), and includes features with no analog in the legacy system. How will the legacy API present a complete picture of such data? What will an existing plugin do if presented with such unrecognized data?
Edit 2: This raises the additional issue that the current Luup API encompasses not just the functions and values/tables found under the
luup global in Lua, but also includes the luup requests that are possible, as many data elements in the system are not accessible except by self-querying the Vera over HTTP. The prototype API documentation uses WebSockets, which is a more complex interface and ill-suited to single query-response, so we already have (a) a gap in the new API (no generic HTTP/HTTPS interface–hopefully they’ll address that), and (b) the uncertainty of whether the “compatibility” API as yet discussed includes the ability to make “old school” luup requests at all–if not, many plugins are DOA.