open-simulation-platform
Plug-in interfaces for observers, connections, etc.
CSE users should have the option to more easily define their own connection types, observers, manipulators, and so on. We simply cannot predict and provide for all use cases.
Right now, any user who wants to do this would have to go into the CSE source code and modify and recompile it to achieve this, which is not an alternative for most.
In the 2019-08-27 status meeting, the following possibilities were enumerated:
- Making these entities scriptable using an embedded scripting language (Lua, AngelScript, Squirrel, etc.)
- Making a C DLL interface, similar to (but hopefully far less elaborate than) FMI.
- Making a C++ DLL interface. This is the shortest path to the goal, but very risky, because C++ ABIs are very sensitive to changes in compilers and compiler settings.
It was pointed out by @lassebje in said meeting that option 1 is the least general, since it can be implemented in terms of method 2 or 3, and that introducing a scripting language is just needlessly complicating things and restricting things for our users. I completely agree with this.
For clarification;
In a C++ software project using the cse-core C++ API (such as cse-consumer) it is fully possible to create your own observer and add it to the execution. Are we talking about something else here?
Ah, I guess that was a bit unclear. By "users" I meant the users of our GUI and CLI, as well as the users of other sofware that builds upon cse-core. What if those users want to add new connection or observer types? Should they have to modify the code of cse-server-go, cse-client or cse-cli to achieve it?
An alternative way to put it would be: Should each cse-core-based software project have to define its own plugin mechanism for observers and connections, or can we define a common one, like FMI gives us for models?
Provided my recent experience with PythonFMU, my suggestion would be to simply use Python.
I'd imagine majority of the users might not know C/C++ (users of client/cli/core4j) and certainly not (Lua, AngelScript, Squirrel etc).
Making a C DLL interface, similar to (but hopefully far less elaborate than) FMI. Making a C++ DLL interface. This is the shortest path to the goal, but very risky, because C++ ABIs are very sensitive to changes in compilers and compiler settings.
Much of the reason this works today is that there are so many tools that exports FMUs form your language/tool of choice. This would not be the case for a cse interface. Right?
Python "everyone" knows. Even if you don't you do.
For reference this is how the C++/Python interaction is implemented in PythonFMU.
