We are currently using the cesium-native library for writing glTF/glb files in our application. Due to the nature of the environments that our software runs on there are some concerns regarding the ownership of the RapidJSON library, to the point that we may not be able to deploy code that uses it. Has this concern been raised before and has there been any discussion of replacing the library with an alternative? Or is there the possibility at least that RapidJSON could be removed from the public interface headers so that we are not required to add an explicit dependency to our software (i.e. using forward declarations or PIMPL idiom)?
@aperuggi What is the issue with RapidJSON? The components of the library we use are licensed under an MIT license, so it is available to use with very minimal restrictions. It’s a high-quality JSON library that performs better than most of the alternatives, and it does not use exceptions which is important for running under Unreal.
It would theoretically be possible to remove RapidJSON from the public API, though this would just be adding a wrapper class around RapidJSON’s document class which would be hard to justify breaking the pubic API for. If this is really a no-go for you, forking cesium-native to implement such a wrapper is an option.
However, I might suggest that the best path forward is to choose a particular version of RapidJSON to pin as your dependency and get that version all checked out and vetted (perhaps as your own fork). This can be done by adding an overlay port - take the vcpkg.json and portfile.cmake for RapidJSON from CMake, put it in an extern/vcpkg/ports/rapidjson folder in Cesium Native, and change the vcpkg_from_github line to point to the commit and repo you would like to use instead. This way you can assure the concerned parties that there won’t be any surprises in the dependency. I would probably suggest pinning to RapidJSON 1.1.0 as this version is almost a decade old so it’s been thoroughly tested and vetted by the community. There shouldn’t be anything in Cesium Native that relies on a newer version of RapidJSON, and if there is it shouldn’t be too hard to replace.
Thanks for the reply. The license and stability isn’t the issue, more that we have some strict deployment requirements regarding the country of ownership (regarding non-US sources) and recency of updates (for which the lack of official tagged releases in the past decade – despite excellent stability – becomes a sticking point). I understand this is most likely a niche concern amongst the global Cesium community so I won’t advocate for a significant change. We can probably work with the overlay port technique that you talked about on our local build of cesium-native and see if that gets us what we need.