-
Notifications
You must be signed in to change notification settings - Fork 17
2024‐10‐15: IFEX Interface translation representation
In later articles, we will investigate the ways we can describe a particular translation from one interface description standard or IDL, to another, and why making that translation easy to understand matters for understanding the IFEX project as a whole. As a basis for that, let's talk first generally about the reasons for the IFEX project, for anyone who still needs an introduction.
When looking at it superficially, people can have a hard time "getting it", but that's probably true for most projects. How does this IFEX thing relate to the landscape of competing formats, projects, implementations? Is IFEX just another Interface Description Language (IDL) that adds to the soup of confusion?
There are different ways to express the IFEX project's goals. Nowadays I usually highlight first that IFEX produces translation tools that will convert between many different existing IDL format, because this is very concrete and easy to understand. At the next level of detail, the IFEX project's purpose is to be a place to do the difficult work of figuring out the semantic meaning, and similarities/differences. This is obviously required to be able to do correct translation, so it is a necessary step.
Next, in order to efficiently achieve the former goals, IFEX needs an internal "model" of interface description which can encompass all the features needed to do translation. Look at these two approaches.
1) <input> -> <output>
2) <input> -> <intermediate-model> -> <output>
We implement the second, because if you want to convert between N different IDLs, you would either need to describe N*N different combinations, or you can to N input filters to the intermediate model, and N output filters, yielding something like 2*N implementations instead.
Finally, the intermediate model can be "printed out", and it can be read back in from a stored representation. This textual representation of the model is the "IFEX Core IDL". Thus, we are adding yet another option to the IDL space, yes, but as a consequence of meeting the other goals.
To this we can add that the IFEX model/IDL uses a strong Layer approach in order to be able to add/remove composable layers of functionality. We take the idea of "deployment layers" pioneered by Franca IDL and extend it further. This layering prevents IFEX to be a kitchen-sink of all possible features in a big mess. The fundamental layer, the Core IDL, is powerful but remains a simple, generic and reusable description of any functional interface.
We could here start describing how IFEX is a more capable interface model, a "better choice" and there are some true reasons to give, such as -> the possibility to separate error types in layers (business logic vs. communications error, for example) and other generic features are better and more expressive than some of the alternatives. But being slightly better is not enough of a reason. The reason the IFEX interface definition model must exist to efficiently meet the goals, has already been explained above - it is a necessary condition to fulfill some of the easy to understand goals.
So IFEX is indeed also "a better mousetrap", but that is of course optional. Adding another "rule them all" option for interface description is naturally contentious, as the XKCD Standards comic reminds us :-)
We could initially therefore focus simply on the value of providing translation tools for already existing standards. Then, for those that are interested, those who really "get it", it is possible to drill down into how to understand interface description semantics in detail and why it requires investigating IDL and interface-models to be able to translate them, and perhaps how the result of that work could lead to, arguably, the most powerful and flexible interface description tool.
A deep understanding about what each interface standard really means is challenging, and mapping one to the other can be even more so. IFEX Project says: Let's work together on that problem! We could here give a name to this semantic understanding and translation: The "Core Challenge".
IFEX is a project to do that work. While doing so, it creates translation tools between IDLs that can be used independently. Since IDLs have different features and idiosyncracies, some sort of generalized interface model is needed to bring them together. The IFEX interface model, as defined by ifex_ast.py in the current implementation, aims to unify different IDL features into a common model, while also using the Layer approach to avoid a kitchen-sink syndrome. This internal model has been created to support the Core Challenge. Competition and innovation can be good but competing is not a solution to the problem of diversity in IDLs and technologies.
IFEX aims to not be another competing option (or at least it does not have to be used that way). The IFEX Project is first of all a place to come together for collaboration. I know that most open-source projects claim this, and this claim often boils down to "come here and collaborate on MY project, instead of yours.", or "We can do it together, as long as the end result is I/we want". Of course, let's honestly acknowledge that there can be some aspect of that in IFEX Project as well, but I believe things can be viewed on a deeper level, and no other project (that we are aware of) take on this Interface-Exchange-Translation challenge in this way.
First let's understand that translating to other IDLs supports a fundamental IFEX philosophy, which is to not reinvent what already exists. Many project claim this, so let's review the details: The purpose of output of existing IDLs is to be able to reuse all the great work that has gone into them! IFEX connects ecosystems rather than trying to make a wall around a new "better alternative". Existing code-generators, bindings, tools, and others are abundant in gRPC, OpenAPI, D-Bus and many other technologies. By outputting these formats from the IFEX framework, we "connect" to those ecosystems. Example: Translating to some IDL that has a good C++ code generator is probably better than writing an IFEX-to-C++ custom generator.
With that said, the approach of writing new IFEX-to- generators is of course available to us, if the situation calls for it.
As described above, IFEX Project is a place to collaborate on the the Core Challenge. To our knowledge it is the ONLY project of its kind, but we're happy to hear if this is not the case - a potential for collaboration. Many interface/protocol technologies focus on doing something for their own use and seem less interested in how this might translate to a competing way of doing things. But some projects indeed consider the ability to connect/reuse what others do by making mappings or translations. Unfortunately some of them end up being theoretcial and not very useful. Like we said, mapping different semantics can be hard, and it requires a very dedicated effort.
If it's true that IFEX is the only project of its kind, then it would turn it the project from "A place" to "THE place" to work on the Core Challenge. But what if it isn't? Well then it just means there are more people working on the Core Challenge, and if results are shared then that should bring us closer to the goal. This is a good thing - assuming the other project is open source licensed of course, so that results can be shared and built on top of.
Is there a similar project out there? Great, let's hear about it! Where are the results that may be part of solving the Core Challenge? Or does the other project only add to the complexity of many competing IDLs? If we are talking about yet another IDL option, it's a matter for the user community to decide if it should be ignored, or if it is worthwhile to map its semantics into the IFEX information model. If it is worth doing, it would concretely mean that this new competing format becomes "supported" as a translation input/output, and in the process create a deep understanding of what it actually offers, and how this might be applicable in projects.
The IFEX Project is interested in hearing if there is any similar work, because it isn't about the end result as much as it is about the learning required to take the next step. The Core Challenge is a non-trivial area, and it is why comparing, sharing, and collaborating is necessary:
Let's break it down one final time:
- If it is a subset of existing features - then perhaps a proposal to be made that it shouldn't be progressed further. Propose that people prefer any another already existing option.
- If it is semantically equal to another existing choice, then again its usefulness might be politely questioned. IFEX is still interested in confirming this semantic equivalence.
- If it includes some new innovative feature - perhaps then we can plug a hole, i.e. something missing in the IFEX "all encompassing" information model (often handled simply by adding a Layer Type to support it). Alternatively we may suggest to the other project that a Layer approach as championed by IFEX (with credit given to its origins in the Franca IDL deployment-modelo) is a better way to add such features to a system.
In all cases, those that are willing to collaborate will benefit from getting together! Get in touch!