...

• Using grpc from web applications currently requires the use of a proxy mechanism as web engine HTTP/2 support is not yet complete enough to allow native implementation.  In practice this means using the grpc-web library with either Envoy (envoyproxy.io) or Improbable's standalone proxy.  Recent discussion in the EG indicates that this is perhaps acceptable in the interim, and that wrapping grpc would be likely be preferable to e.g. D-Bus if development on WAF API extensions ends up still being required.  Additionally, the Cloud EG has indicated that Envoy is potentially something they would be interested in seeing available to ease service mesh demonstrations.
• Toyota have indicated that they considered using grpc for APIs in their own internal Flutter application development, but decided to move to using custom Flutter platform channel API wrappers (similar to what is done with WAF + web apps) for currently unquantified performance reasons.  However, they agree that using grpc for AGL developed demo services seems a reasonable approach.

Replacing SMACK

The SMACK Linux Security Module (LSM) at this point is mostly only used by Samsung in their now mostly internal Tizen development.  As mentioned above this was one of the motivations for removing the previous application framework.  However, it seems reasonable to attempt demonstrating one of the more commonly used LSMs, e.g. SELinux or AppArmor.  Multiple AGL member companies have indicated they use SELinux in their products, so investing effort into some form of enablement / technology demonstration in upstream AGL seems worthwhile if done in a modular fashion.

Proposed Development Tasks

...

1. Add discovery and launching of AGL applications via the systemd D-Bus API.  AGL applications would provide a systemd user unit applaunchd could discover via the systemd API and then stop/start in response to its own API mechanism.  The goal would be to at first deprecate, and then obsolete (for e.g. the Octupus Octopus 15.0 release) the direct spawn and D-Bus activation schemes currently implemented.  Potential standardization/templating of application systemd units and whether to still rely on the use of .desktop files is something that would require investigation and discussion in the EG.  A lesser reason for using systemd units rather than D-Bus or direct launching is for an improvement in logging, a discussion on this can be found in the comments on SPEC-4211.
2. Add a grpc API that duplicates the current D-Bus one, with an eye towards potentially obsoleting the latter in a future release once grpc use is better understood.  Rework of the demo homescreen and launchers to use the grpc API would likely be part of this effort unless a separate test application is developed.

...

1. Develop a grpc API provider for the previous agl-service-audiomixer binding, to allow for both the Qt and web app demo mixer applications to be reworked against it and re-added to their demo images.  This would act as a frontrunner for demonstrating using grpc/protobufs in AGL potentially in parallel with (2) above, though it may be more straightforward for one or the other to be chosen as an initial project to establish an example.  The audio mixer binding is viewed as a good example service to reimplement in that the PipeWire and WirePlumber APIs it wraps will require non-trivial development to re-enable in demos no matter the approach taken.
2. In parallel with (1), start an investigation into the feasibility of enabling grpc-web usage in the demo web apps.  This will involve evaluation of making Envoy or Improbable's proxy available inside of AGL with respect to build and configuration, and once that is in hand attempting a demonstration of using an API in a web application with grpc-web.  It is possible (or perhaps likely) that this may need be decomposed into separate tasks for the build versus web app development components.
3. Once the audio mixer and/or application launcher APIs have been shown feasible, move on to reimplementing some of the other binding services that have no available FOSS API mechanisms that are easily leveraged, with likely priorities being services such as the radio and the HVAC bindings.  It is likely that services such as telephony are good candidates here as well, since their APIs are relatively simple and development of some kind would be required to (re)integrate them into the demo applications in any instance.  From a technology demonstration perspective, once there are some examples in hand there may be opportunity to drive member engagement on API requirements with respect to serving as useful abstraction layers for proprietary implementations.  Potential rework of the Bluetooth, network, and media playing APIs should only be considered once it is clear that the grpc approach is workable and that follow on maintenance will not be a significant issue.  Bluetooth is one area where there has previous been member interest in working on a reusable API, so that might make it a more worthwhile candidate for attempting later in 2022.
4. Investigate enabling and using the grpc API in the kuksa.val vehicle signaling framework.  The planned use of kuksa.val in Marlin 13.0.x will be limited to the standard VISS WebSocket API due to build issues stemming from that project's use of CMake intersecting with a known upstream OpenEmbedded/Yocto Project limitation.  Working with upstream of potentially both projects will be required to enable using grpc with kuksa.val, with a potential significant benefit to OE/YP/AGL ecosystem use of grpc in the future.  One note with respect to this effort is that some care will need to be taken in any of AGL's own development around grpc to avoid use of the CMake grpc module until the issue with it can be resolved with upstream.
5. Outside of base grpc usage, authorization and service discovery are functionality that need further research and development to work towards a complete technology demonstration.  It is likely that the two features need separate research tasks that would lead to potential development later in 2022 or in 2023 once the EG reaches some consensus on any proposed development stemming from the research.  There is some potential on both fronts to work with the Cloud EG in requirements definition and development, as their micro-services and service mesh plans have overlaps in these areas.  One point of concern that will likely need to factor into research in this area is that some of the available solutions in at least the service discovery side are somewhat heavyweight for an embedded/automotive system, this is likely another area where there is some good synergy with the Cloud EG plans, as it is also a concern for them.

SELinux

Development tasks:

1. Add the meta-selinux layer to the default AGL demo image builds, with an initial goal of getting builds working with the upstream targeted reference policy in permissive (i.e. non-enforcing / warning) mode.  The aim would be to have the SELinux kernel configuration, tooling, and base reference policy available in the AGL infrastructure for members to leverage.
2. Start an investigation into the iterative effort to tweak the SELinux policy to allow running the AGL demo images with SELinux in enforcing mode.  This should ideally involve with working with meta-selinux upstream, as currently this is not possible when using systemd in even a plain core-image-minimal Yocto image.  It is not expected that this work would be completed in 2022, though there is some potential for being able to enable demos on telematics or cloud gateway demos.  Demonstrating the ability to have SELinux work in enforcing mode in a non-IVI image with a container engine runtime may be an achievable goal for 2022, and has good synergy with Cloud EG requirements.