Hello all,
regarding the generic controller plugin, we at ADIT have largely enhanced it to suite our customer requirements. The version maintained by ADIT and used in our customers projects is close to ~350 commits ahead of the latest common ancestor tagged '7.3' with some changes from 2016.
According to its original design, the generic controller plugin still can be characterized through below conceptual guidelines:
Topology:
Elements like sources, sinks and gateway are hosted in routing-side domains
Converters are not supported
Sources and sinks are (mandatorily) grouped through assignment to a class element
Allowed streaming routes are specified for mentioned class elements
Expected system topology with domains as well as static sources, sinks and gateways shall be pre-configured in configuration-XML file
Dynamic sources, sinks and / or gateways can be allowed. Such dynamic elements are to be registered at runtime from routing side.
Events:
User requests from command side, as well as registration requests and change notifications from routing side are abstracted as incoming events and immediately converted to trigger objects
A trigger object memorizes the details of an event.
Trigger objects are queued and processed sequentially, one at a time.
While processing a trigger, appropriate action object(s) are created and configured according to business logic
Action Handling:
Action objects are queued and executed sequentially, one at a time
Action objects can have embedded child actions
Action objects, while executing, usually launch commands to the routing side and/or notifications to the command side
Action execution may be suspended while waiting for completion of an asynchronous operation on routing side. On reception of the response it is resumed automatically.
Missing responses (acceptable duration is configurable) cause rolling back the current action
Error responses from routing side causes the current action to roll back
Project-specific policies:
Project-specific business logic is represented as policy rules and given in XML format
Action(s) to be executed are selected and configured per event details
Event details are determined from trigger type and trigger parameters
Action behavior can be fine-tuned through action parameters
A family of functions and macros is available to evaluate policy conditions and action parameters
Our changes mainly relate to structural simplifications, policy evaluation capabilities and documentation updates.
With respect to above aspects the current version is a robust, stable and flexibly configurable component which serves the needs of several different project topologies.
Probably the most important drawback of our changes is the format change for the topology and behavior specification XML. Although the information content has evolved only slightly, the new format makes extensive use of XML attributes instead of child elements and thus allows for significantly shorter coding. The parser was updated in one shot without any backward compatibility. So upgrading to the new version requires to re-write customer configurations.
Due to the huge amount of differences between the current OSS version and the recent version hosted on ADIT servers I consider it far too expensive in effort to create a pull request for each commit or even each modification set. Therefore I propose updating the whole component in a single replacement commit.
Thus I would like to check with you
if anyone needs continuous support for the old XML format because he/she tends to update, but has configurations installed with the current OSS format
if we need to setup some kind of stabilization branch to retain the current OSS version (tag '7.6', VERSION 7.4.0 as of CMakeLists.txt)
how we should deal with the version identifier (this should be at least a major version increase)
Your comments are welcome & Best regards
Martin Koch
Advanced Driver Information Technology GmbH
Engineering Software Multimedia (ESM)
Robert-Bosch-Str. 200
31139 Hildesheim
Germany
Hi Martin,
That's great news. To be honest, in my opinion this is one of the most important components in GAM and I´m very happy to see the GC now available for everybody.
We are using it since the beginning and I started really to love it ;-) .
Since the first versions, there were a lot of improvements done. Especially the new XML format and use Functions in Actions giving you the possibility to configure even more complex projects without losing the overview. Also the new volume handling is really great.
While the first GC configurations took more time, in the meanwhile we are down to roughly a day to configure the AM requirements in a project. The GC helps here a lot, e.g. with the intelligent and well-structured volume handling.
There are so many other great things to tell about the GC, but best everybody just start using it :-D .
Also a small recommendation, try to get to the new XML structure as soon as possible. It is really worth the effort. We reduced the configuration size by >2/3.
Behind every great component is an even greater team (sorry, I was not able to skip that :-) ): thanks Martin and all who actively develop on this component. You really did and are doing a great job.
Mit freundlichen Grüßen / Best regards
Thomas Wiskot
CM-CI2/ECS3
-----Ursprüngliche Nachricht-----
Von: genivi-audio-manager genivi-audio-manager-bounces@lists.genivi.org Im Auftrag von Koch, Martin (ESE GmbH; ADITG/ESM)
Gesendet: Montag, 10. Februar 2020 14:47
An: GenIVI AudioManager Mailing list (genivi-audio-manager@lists.genivi.org) genivi-audio-manager@lists.genivi.org
Betreff: [audio-manager] GenIVI Am - Generic Controller Plugin - new version announcement
Hello all,
regarding the generic controller plugin, we at ADIT have largely enhanced it to suite our customer requirements. The version maintained by ADIT and used in our customers projects is close to ~350 commits ahead of the latest common ancestor tagged '7.3' with some changes from 2016.
According to its original design, the generic controller plugin still can be characterized through below conceptual guidelines:
Topology:
Elements like sources, sinks and gateway are hosted in routing-side domains
Converters are not supported
Sources and sinks are (mandatorily) grouped through assignment to a class element
Allowed streaming routes are specified for mentioned class elements
Expected system topology with domains as well as static sources, sinks and gateways shall be pre-configured in configuration-XML file
Dynamic sources, sinks and / or gateways can be allowed. Such dynamic elements are to be registered at runtime from routing side.
Events:
User requests from command side, as well as registration requests and change notifications from routing side are abstracted as incoming events and immediately converted to trigger objects
A trigger object memorizes the details of an event.
Trigger objects are queued and processed sequentially, one at a time.
While processing a trigger, appropriate action object(s) are created and configured according to business logic
Action Handling:
Action objects are queued and executed sequentially, one at a time
Action objects can have embedded child actions
Action objects, while executing, usually launch commands to the routing side and/or notifications to the command side
Action execution may be suspended while waiting for completion of an asynchronous operation on routing side. On reception of the response it is resumed automatically.
Missing responses (acceptable duration is configurable) cause rolling back the current action
Error responses from routing side causes the current action to roll back
Project-specific policies:
Project-specific business logic is represented as policy rules and given in XML format
Action(s) to be executed are selected and configured per event details
Event details are determined from trigger type and trigger parameters
Action behavior can be fine-tuned through action parameters
A family of functions and macros is available to evaluate policy conditions and action parameters
Our changes mainly relate to structural simplifications, policy evaluation capabilities and documentation updates.
With respect to above aspects the current version is a robust, stable and flexibly configurable component which serves the needs of several different project topologies.
Probably the most important drawback of our changes is the format change for the topology and behavior specification XML. Although the information content has evolved only slightly, the new format makes extensive use of XML attributes instead of child elements and thus allows for significantly shorter coding. The parser was updated in one shot without any backward compatibility. So upgrading to the new version requires to re-write customer configurations.
Due to the huge amount of differences between the current OSS version and the recent version hosted on ADIT servers I consider it far too expensive in effort to create a pull request for each commit or even each modification set. Therefore I propose updating the whole component in a single replacement commit.
Thus I would like to check with you
if anyone needs continuous support for the old XML format because he/she tends to update, but has configurations installed with the current OSS format
if we need to setup some kind of stabilization branch to retain the current OSS version (tag '7.6', VERSION 7.4.0 as of CMakeLists.txt)
how we should deal with the version identifier (this should be at least a major version increase)
Your comments are welcome & Best regards
Martin Koch
Advanced Driver Information Technology GmbH
Engineering Software Multimedia (ESM)
Robert-Bosch-Str. 200
31139 Hildesheim
Germany
genivi-audio-manager mailing list
genivi-audio-manager@lists.genivi.org
http://lists.genivi.org/mailman/listinfo/genivi-audio-manager_lists.genivi.org