Update on the upcoming release

Zaid Abdulla zaid at genieacs.com
Sun Mar 6 16:27:51 EST 2016


This is long over due, but the foundations of the upcoming release are
finally in place. I won't go into too much into details here but I just
want to give some update and let everyone know what to expect. This is
quite a big change in the inner workings of GenieACS that opens the
door for even more improvements in the future such as support for
different database back ends, to name one.

The version number is going to be v1.1 which means that the API,
database structure, and configuration files are going to backward
compatible for the most part. While this is a minor version bump, so
much has changed under the hood that I will need to implement a few
shims to maintain API compatibility. Most notable is the abandoning of
"tasks" in favor of a declarative approach to pushing changes. Support
for tasks in API will be implemented by a compatibility layer that will
eventually be deprecated in future releases.

So here's what's in store for the upcoming release:

- Virtual parameters: These are user defined parameters that are backed
by a custom script and are accessible just like regular parameters. The
script can read and write other parameters so the possibilities are
endless. You can, for example, implement a virtual parameter for Wifi
key that will set set the Wifi key or disable authentication if an
empty string is provided. This can also be useful for working around
device quirks or to create unified parameters that work seamlessly
across different device models.

- Parameter wildcard and aliasing: In scripts and presets, parameter
paths can include asterisks (*) or key:value filters. Say you want to
set the username of the one WANPPPConnection that is enabled, you'd use
a path like this to refer to that particular instance:
"InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANPPPConnecti
on.[ConnectionStatus:Connected].Username". This is somewhat similar to
the alias-based addressing mechanism as defined in the protocol specs,
but this is a server side implementation that doesn't require explicit
support for it from the device. There's also the added bonus of being
able to use any one (or more) of the sub parameter to define the alias.

- Scripted presets. Need I say more? :)

- Time and event based presets: It will be possible to restrict presets
to certain device events (e.g. bootstrap) or use cron-like expression
to activate a preset at different times.

- Fixing some deep-rooted limitations in presets around creation of
nested object instances.

I'm targeting mid April for the release. I hope it won't slip much
later than that. Feel free to experiment with it until then and share
any thoughts or feedback.

Zaid


More information about the Users mailing list