[Bf-committers] JSON/YAML parsing in CPP

Ray Molenkamp ray at lazydodo.com
Wed Sep 15 17:18:20 CEST 2021

My official position is : The platform module is
not in the business of making library recommendations,
or deciding what library does or doesn't go into blender.

As long as the admins are willing to sign off on it,
we'll build any library you want, with whatever options
you require. When the render module goes "hey we need
the vulkan SDK" it's really not our place to go "lol
no! Go write a DX12 or Metal back-end instead". A module
has a need and it's the platform modules job to
support that need to ensure their success.

Once a decision to gain an additional dependency has been
made, we'll go out of our way to ensure a smooth landing
in the blender Eco-system, no need to concern your self
with platforms, compiler flags, linkers or build systems,
we got this! Once we're done the module should just be able
to #include "libfoo.h" and be on their way.

In short, the platform module is essentially a service
module to empower the other modules to do their work
with the least amount of distractions from the platform
side of things. However your needs are your needs, building
libfoo vs building libbar it's honestly all the same to us.
So with that said and hopefully clarified that my personal
opinion on this subject should hold no more value than
any other blender contributor.

"I need a Yaml, or Json library" from the tone of
your email you don't really seem to care what format
one or another, would you accept XML? we already have
and ship pugixml, opinions may be divided here but I'd
rate XML human readable. We could bump it from optional
to required with virtually no work.

T91430 seems to hint that you'd like a C++ API, if that's
the case nlohmann's library [1] is by far the most pleasant
library I've used. rapidjon or simdjson (read-only) may have
the performance edge, but there's something to be said for good looking
maintainable code especially if we're not going to end up parsing
gigabytes of json.

Whatever you decide on doing, I understand time is of
the essence, and I will make myself available to make
whatever option you chose available to you as quickly
as possible.


[1] https://github.com/nlohmann/json

On 2021-09-15 3:22 a.m., Jeroen Bakker via Bf-committers wrote:
> Hi All,
> For the asset browser we would like to store an index per asset file
> (.blend file inside an asset library) to reduce the overhead of showing
> assets in the asset browser.
> The high level solution we are thinking of is to store an index file next
> to the asset file that can be read quickly to find out what assets are
> inside the file. The challenge I want to address is the used data format of
> that file. We prefer these supporting files to be human readable, but the
> structure can be complex. From this point of view we are looking for
> Currently we don't have a YAML/JSON parsing library in our core. As we want
> to add indexing still as part of Blender 3.0 we might have a timing issue.
> In https://developer.blender.org/T91430 2 valid options are desribed.
> - use a header only JSON parser.
> - use cpp-yaml that is already used by OCIO/OIIO and make it a hard
> dependency.
> T91430 also mentions an abstration to switch implementations if needed.
> We would like to have discussion/feedback from the platform maintainers to
> see what would be a valid option for inclusion of asset indexing in Blender
> 3.0.
> Jeroen
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list