You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that NMOS is expanding in several more directions, it would be good to demonstrate that nmos-cpp is not monolithic.
Suggestion: build/compile-time options that show the modularization possibilities...
IS-04 and IS-05 should always be included in libnmos
BCP-002-01 always included (v small)
BCP-002-02 always included (v small)
probably BCP-004-01 always included
most others should be possible to opt out at build/compile-time
IS-07
IS-08
IS-11 and IS-12 (when merged)
maybe IS-13 (when merged)?
maybe IS-09?
maybe IS-10 (when merged)?
what about support for different media formats... can these be modularized?
video/raw (ST 2110-20)
audio/L (ST 2110-30)
video/smpte291 (ST 2110-40)
video/SMPTE2022-6 (ST 2022-8)
video/jxsv (ST 2110-22, BCP-006-01)
video/H264 (when implemented per BCP-006-02)
video/H265 (when implemented per BCP-006-03)
etc.
In an ideal world, I would expect that using explicit build/compile-time options would make little difference to the overall code size vs. using current libnmos.a static library, since linker should be clever enough to remove unused objects... However, I know that there are some objects that will currently tie everything together, e.g. nmos/json_schema.cpp and nmos/node_server.cpp.
Another possibility is just to show in nmos-cpp-node how to exclude the various optional APIs like IS-07 and IS-08.
The text was updated successfully, but these errors were encountered:
Now that NMOS is expanding in several more directions, it would be good to demonstrate that nmos-cpp is not monolithic.
Suggestion: build/compile-time options that show the modularization possibilities...
In an ideal world, I would expect that using explicit build/compile-time options would make little difference to the overall code size vs. using current libnmos.a static library, since linker should be clever enough to remove unused objects... However, I know that there are some objects that will currently tie everything together, e.g. nmos/json_schema.cpp and nmos/node_server.cpp.
Another possibility is just to show in nmos-cpp-node how to exclude the various optional APIs like IS-07 and IS-08.
The text was updated successfully, but these errors were encountered: