Lars T. Kyllingstad

I understand and agree, and I think that a prominent warning in the package revisions documentation would be a satisfactory solution.

I'd be happy to draft the minimal description I suggested at the end and submit a PR if this is desirable.

Suggestions for suitable storage formats are welcome. Note that according to the FMI spec, each subsimulator does its own serialisation and deserialisation, and all the co-simulator sees are binary blobs....

There are plenty of issues with the names we use in our API, but I am more worried about their lack of precision and descriptiveness than I am about their...

@davidhjp01, you [asked in another issue discussion](https://github.com/open-simulation-platform/libcosim/issues/756#issuecomment-2418757975) whether you should start working on this issue. But as noted in the issue description, this depends on #768, which is a work...

Nice summary. Without having spent a lot of time thinking about this, I immediately lean towards the simple and efficient schema-less formats, i.e., MessagePack, CBOR, or BSON. I don't have...

I do have [experience](https://github.com/viproma/coral) with Protocol Buffers, though, and while it is good in terms of performance and built-in versioning, I think I'd prefer to avoid the extra compilation step...

@davidhjp01 wrote (in what I suspect was [the wrong thread](https://github.com/open-simulation-platform/libcosim/pull/777#issuecomment-2494132087)?): > Just leaving some ideas here - I have used `nlohman_json` before and I liked it, and seems it has...

> I'm not sure it can replace Boost PropertyTree, though. […] I started using it as a generic data type in #769. Or was that actually where you suggested replacing...

I have some funding to work on this this autumn, so I assigned it to myself.