The following members were present
Andreas Benzing (Canoo Engineering AG)
Jan Blockx (Siemens AG)
Stefan Ebeling (BMW AG)
Sibylle Peter (Canoo Engineering AG)
Stefan Wartini (MÃ¼ller-BBM VibroAkustik Systeme GmbH)
Matthias Koller (Peak Solution GmbH)
The following members were absent
Stefan Beese (Bertrandt Services GmbH)
Gerd Weckenmann (AUDI AG)
2.1. Performance Issues
The current structure of the openMDM web client together with the openMDM API is not well suited for the implementation of the search function currently carried out by Matthias Koller (Peak Solution GmbH). In the API, every entity is loaded separately, leading to unnecessary overhead and poor performance. In addition, the search over multiple storage locations can only be done by querying each source and combining the results in a module "above" the openMDM API. The initial proposal by Matthias Koller (Peak Solution GmbH) to address these issues is to move the search functionality further down the stack.
The situation is discussed among the participants. In general, the API should not be modified to ease the implementation of new functionality but only if such a change is required to facilitate the implementation. Otherwise, new modules and features would frequently result in API changes, contradicting the idea of a stable openMDM API.
While all agree that performance is a crucial topic, the place to implement a multi-source query is in tension. In the current architecture, such a functionality would be placed in the connector service. However, implementing a full-featured connector service for the current task would take very long and besides the search, the requirements for the service are currently unclear.
Some remarks about the API have already been gathered in the course of implementing a PAK cloud adapter as a second persistence option. These findings will be provided to the members of the Architecture Committee and Matthias Koller (Peak Solution GmbH) for review. A detailed suggestion on how to implement the search along with potentially required changes to the API should then be discussed and agreed upon among the committers of the affected projects.
3. Next Meeting
The next meeting is scheduled for February 03, 2017, 09:00 CET.