<div dir="ltr">Hello Zaid,<div>  I presume the preset scripts will be nodejs scripts? Also, am I reading it correctly that a preset script can be bound to 1 or more events?</div><div><br></div><div>-dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 12:27 PM, Zaid Abdulla <span dir="ltr"><<a href="mailto:zaid@genieacs.com" target="_blank">zaid@genieacs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is long over due, but the foundations of the upcoming release are<br>
finally in place. I won't go into too much into details here but I just<br>
want to give some update and let everyone know what to expect. This is<br>
quite a big change in the inner workings of GenieACS that opens the<br>
door for even more improvements in the future such as support for<br>
different database back ends, to name one.<br>
<br>
The version number is going to be v1.1 which means that the API,<br>
database structure, and configuration files are going to backward<br>
compatible for the most part. While this is a minor version bump, so<br>
much has changed under the hood that I will need to implement a few<br>
shims to maintain API compatibility. Most notable is the abandoning of<br>
"tasks" in favor of a declarative approach to pushing changes. Support<br>
for tasks in API will be implemented by a compatibility layer that will<br>
eventually be deprecated in future releases.<br>
<br>
So here's what's in store for the upcoming release:<br>
<br>
- Virtual parameters: These are user defined parameters that are backed<br>
by a custom script and are accessible just like regular parameters. The<br>
script can read and write other parameters so the possibilities are<br>
endless. You can, for example, implement a virtual parameter for Wifi<br>
key that will set set the Wifi key or disable authentication if an<br>
empty string is provided. This can also be useful for working around<br>
device quirks or to create unified parameters that work seamlessly<br>
across different device models.<br>
<br>
- Parameter wildcard and aliasing: In scripts and presets, parameter<br>
paths can include asterisks (*) or key:value filters. Say you want to<br>
set the username of the one WANPPPConnection that is enabled, you'd use<br>
a path like this to refer to that particular instance:<br>
"InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANPPPConnecti<br>
on.[ConnectionStatus:Connected].Username". This is somewhat similar to<br>
the alias-based addressing mechanism as defined in the protocol specs,<br>
but this is a server side implementation that doesn't require explicit<br>
support for it from the device. There's also the added bonus of being<br>
able to use any one (or more) of the sub parameter to define the alias.<br>
<br>
- Scripted presets. Need I say more? :)<br>
<br>
- Time and event based presets: It will be possible to restrict presets<br>
to certain device events (e.g. bootstrap) or use cron-like expression<br>
to activate a preset at different times.<br>
<br>
- Fixing some deep-rooted limitations in presets around creation of<br>
nested object instances.<br>
<br>
I'm targeting mid April for the release. I hope it won't slip much<br>
later than that. Feel free to experiment with it until then and share<br>
any thoughts or feedback.<br>
<br>
Zaid<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.genieacs.com">Users@lists.genieacs.com</a><br>
<a href="http://lists.genieacs.com/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.genieacs.com/mailman/listinfo/users</a><br>
</blockquote></div><br></div>