General Information

Welcome to the Interface Exchange Project (IFEX).  IFEX is a general interface description and transformation technology which started in the Vehicle Service Catalog (VSC) project. The technology (IFEX) is now developed under a separate name to better describe its purpose and that it is widely and generally applicable.

Weekly Dev Meeting: Wednesday, 4-5pm CEST / 10-11am PT / 7-10am PT - (Zoom Link) (Subscribe to Community Calendar to stay up to date)

Slack: https://covesacommunity.slack.com/archives/C05EZJ6K1K2 (Common Vehicle Interfaces)

GitHub:  https://github.com/COVESA/ifex

Project Leads:

• Gunnar Andersson , MBition

Compliance statement:

Antitrust
Before we begin, we would like to make clear that COVESA is committed to compliance with the antitrust laws in all of its activities, and that it expects all participants to similarly comply with the antitrust laws.  We will not engage in--and members must refrain from--any discussion of, or understandings regarding competitively sensitive topics. If you have any doubts regarding whether a matter is appropriate for discussion, please consult with your antitrust counsel.

Open and Royalty-Free
Further, COVESA aspires to be an open and royalty-free organization. The discussions and contributions made during this session are governed by the COVESA Intellectual Property policy. If you are unfamiliar with that policy, please review it in detail prior to making any contribution that reads upon a patent.

IFEX Development Meeting Minutes

2025-02-05

Start 16.00
 

Participants:

Sri Palacharla, General Motors

Gunnar Andersson, MBition
Kevin Karl, Volvo Cars

 
Minutes:

- Kevin ran the container setup successfully after updating to latest commits (new file structure)

- Q: Should the container have root access, if additional tools need to be installed?

A: The container was designed only to support basic CI test, or to give a guaranteed workable environment to test the tools in a simple way.  If it is going to be used for development, it might need improvements.

Looking into how it is defined - Ubuntu container uses the ubuntu user which is delivered with the distro - and it should have sudo access?  On Alpine, a specific user is defined in the Dockerfile, but added to wheel group - also supposed to give it sudo access.

TODO: Try/verify if this is true.

- For the future consider something like Devcontainers https://containers.dev to set up a more full featured environment?  (contributions welcome)

- Q: What's the idea with /work directory for the containers?

- A: Nothing in particular really, it is currently just a way to map in the local directory to be able to work.  We noticed however, the Dockerfile also copies the files into the container.  Depending on the intended use (just run tests in CI, or provide an end-user or developer environment), this might warrant some rework

- Q: If editing files on the development host, how is it reflected in the container?

- A: Probably worth looking over the containers and make a development-oriented setup in which the project directory is mapped into the container, instead of copied.  Current setup appears to do both – copies the files so that they are guaranteed available for running the commands (CI tests, etc.), but also mapping in the current-working-directory when using the interactive target.  However, we found that maybe it is mapping the wrong directory – a bug stemming from directory reorganization.

• It's also of course possible to run a custom container bring-up command, independent of what the Makefile provides.

Also, noted that the Makefile has some support for adding a :z flag to the volume mapping.  This is required only on RedHat based distros running SELinux, not affecting for example an Ubuntu host system.

- Q: I previously had some failure related to `glib` during installation?

- A: Haven't seen glib problem per se, but there are some dependencies, mostly the lxml package I think, that are compiled with a C-compiler.  Please report exact issues so they can be evaluated.  Overall, the only effective way to handle "works/fails on my machine" is to strengthen the CI/CD tests on multiple environments, and the container setup.

- Q: JSON-schema, why do we need it?

- A: A JSON-schema can be used to validate YAML input.  Most IFEX tools, and the documentation generation, takes its formal definition of the IFEX model and core language from the "ifex_ast.py" source code file.  This is our single source of truth.  However, some IFEX software exists written in alternative languages, and likely more in the future.  They won't process the python-file effectively, but still need a formal definition.  Therefore JSON-schema is generated out of ifex_ast, to support such development.

  In addition to alternative implementations of tools:

  1) Anyone may optionally use a JSON-schema validator, to validate files written in the "IFEX Core IDL" YAML format

(Note:  This might even give better error information than the current IFEX tools default parser does).

  2) With plugins, the JSON-schema can be fed into VSCode and the result is an automated syntax-checker functionality in the editor that will help anyone write correct IFEX YAML format directly.

- Q: How to run tests?

- A: Go through the installation instructions in README (venv, requirements.txt, and pip install -e), and then run pyenv.  Instructions are also in the README.

Gunnar summarized the exchange as fruitful as it answered questions necessary to bring Volvo up to speed to be able to use and contribute.  Gunnar reiterated the need for companies to commit to providing development input to the project, and participate in the dev meetings if they are going to be worth having.

Finally, noted that the related IFEX-ARXML project is now  “Go” inside AUTOSAR.

Meeting ended ca 16.40
Minutes by Gunnar Andersson

2024-01-22

Planned start 16.00

Trouble with Zoom again – a new Zoom link was created, and shared in the CVI-channel of the COVESA chat.

Actual start, around 16.15

Participants:

Gunnar Andersson, MBition

Halim Ragab, General Motors

Minutes:

Rules of collaboration

Discussed that shared open-source project exchange may directly or indirectly convey some of the companies’ technological preferences and that OEMs have software development on multiple levels – legacy, current, and future, or simply research/investigation.   Agreed that expressing general interest or support for a particular technology does not require association with anything specific to still lead to successful shared exploration. Such opinions and interests can often be expressed generally and not in an association with particular products, nor the type of development (production-related vs. research).   In the context of the IFEX Development Meeting, an example of such interests may be which specific interfacing technologies would be prioritized within the IFEX translation framework development. 

IFEX project

Going through the IFEX issue-tracker [1] to find “easy tasks” to get started with for contribution of code into the IFEX project.

Discussed the particulars of the already implemented D-Bus support, as an interesting challenge for interface expression and translation, wherein on one hand the XML-based format is easy to parse but on the other D-Bus has a few quirks that need consideration.  For example, D-Bus XML descriptions express only “anonymous” datatypes in message content, without specifying parameter names.  Instead there is an overlayed discovery protocol for viewing the names of methods and their arguments, (which can be seen more as a recommended service design, rather than being part of D-Bus definition format itself).  IFEX and many environments always name the data items in a structure (for example) which means such names might have to be generated in one direction, and thrown away (or added as a comment) in the other.
(Note: Not mentioned in the meeting, but the IFEX format also supports anonymous items by simply naming them ‘_’  (the underscore character)).

Discussed the current level of implementation for Protobuf/gRPC translation in IFEX, and testing it on uServices (= an open-source collection of interface definition that has been published by General Motors, and is currently expressed in protobuf/gRPC IDL).   Some challenges are around the Protobuf/gRPC “options”-feature, which might be used in company-specific ways and that makes it harder for a translator to have a clear semantic meaning of the very generalized feature of “options”

We also talked about that the OpenAPI and AsyncAPI interface description languages (and their associated tools/ecosystem of course) are interesting to implement soon, due to their wide usage, and they are also technically interesting (i.e. challenging) because of very specific assumptions about the style of interface and other conventions.  (In particular for OpenAPI – RESTful principle and HTTP protocol influence is significant).

Meeting ended 16.37
Minutes by Gunnar Andersson
[1] https://github.com/COVESA/ifex/issues

2024-01-15

Planned start 16.00

Participants:

Magnus Feuer, Volvo Cars

Kevin Karl, Volvo Cars

Gunnar Andersson, MBition

Richard Fernandes, General Motors (joining 16.45)

Problems with Zoom because the Zoom host could not join us. 
=> starting late with a new zoom invite which was shared on the common COVESA chat system so that everyone is able to attend.  30 minute limit.

Started approximately 16.20

New participant from Volvo: Kevin Karl.

In the absence of Paul (COVESA), an explanation from Magnus Feuer, complemented by Gunnar Andersson, about Antitrust requirements.
The exact scope of discussion reiterated, as follows:

• Technical needs or proposals, which are not associated with any specific project information, can be communicated in the interest of finding technical solutions in the common open-source implementation project (IFEX).  We can further discuss how to create IFEX technology that solves those aspects.
• Market driving or competitive information, not limited to product plans, pricing, implementation timing, and related issues, must not be mentioned at any time.

Technical exchange started.

Personal introductions.

Volvo Cars expresses interest in contributing to the development of open-source IFEX implementations, and expresses need for AUTOSAR support.

Gunnar expresses that additional developers should provide code for the project.

Kevin had some issues getting things running.  Checking together that the setup is working without bugs.  According to the GitHub workflow jobs, it seems to be.  To be checked again after the meeting.  Kevin to restart with the latest new file structure.

Gunnar explains new file/directory structure in IFEX code project.

Questions:

1)  Can more than one interface belong to one namespace?  (How should it work?)

Answer: Yes, the concept is designed for that.  Current implementations process one file at a time, which seems enough for the needs of converting between IDL formats now, but might need to change in the future. In general, any (new) tools such as a code generator, would decide themselves how they must process inputs (one or several files at a time) and are simply expected to behave correctly (for example if two different files refer to the same namespace, then the two interfaces are handled as if that is indeed the same namespace).

2) What is the difference between Interface Language and Interface Model?

Answer (summarized):  The interface model is the underlying representation of an interface in the IFEX environment.  It is there to represent Interfaces, regardless of how they were defined (in different IDLs).  However, when you “press print” (symbolically) on the internal model, the result is IFEX Core IDL, the YAML format.  There is a one-to-one representation of items seen in the YAML text and the internal model.  Depending on which point to get across, the terminology IDL and model may be interchangeable. 

Richard/GM joined the meeting approximately ca 16.45

Further discussions.  An important concern is to understand why we do IFEX (Reason, summarized:  Existing alternatives may fulfil the need of a particular interface environment, but do not fulfill the need of the “common model” required to represent all styles of interfaces – more details on this are available through additional reading)

Meeting ended 16.52

Minutes by Gunnar Andersson