genivi-audio-manager@lists.genivi.org

development list for the AudioManager

View all threads

GenIVI Am - Generic Controller Plugin - new version announcement

KM
Koch, Martin (ESE GmbH; ADITG/ESM)
Mon, Feb 10, 2020 1:47 PM

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

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
WT
Wiskot Thomas (CM-CI2/ECS3)
Mon, Feb 17, 2020 7:55 AM

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

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