Sweetcomb/VOM

VOM as a middleware

These efforts have started with this Proof of Concept. This demonstrates that it is possible to have the unmangled C symbols that sysrepo requires to dynamically load the shared library though developping the library in C++.

Read [ https://tools.ietf.org/html/rfc8342#section-5.1.4 this ] passage from RFC 8342. VOM has the same property as the intended datastore but it is not expressed in YANG.

Advantages/Inconvenients

Advantages of using VOM over scvpp:

1. VOM offers a much more backward compatible API than VAPI.
2. VOM is used in other projects like opflex-vpp (less bugs/more contributions)
3. VOM::OM::replay can recommit configurations in case of failure of VPP
4. VOM is part of VPP so changes of definition in "api" files will be updated in VOM too by VPP maintainers.

Inconvenients:

1. VOM is very good to configure VPP but not to fetch information from it as it outputs dumps in a string format which needs to be parsed (problem of types, ...)
2. VOM stores as: (key, list(objects)). The problem is that deleting a key will delete the entire list of objects so keys SHOULD BE uniquely choosen for each object (interface, route, etc...)
3. Most VOM operations are not thread-safe
4. Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance.