View source for Sweetcomb/VOM

== VOM as a middleware ==

These efforts have started with this [https://github.com/YohanPipereau/vomcomb  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:'''

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

'''Inconvenients:'''

:# 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, ...)
:# 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...)
:# Most VOM operations are not thread-safe
:# Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance.