[Bf-committers] JSON/YAML parsing in CPP

Jeroen Bakker jeroen at blender.org
Fri Sep 17 12:50:05 CEST 2021


Hey Ray,

thanks for the clarification on the platform module. I did a quick search
and couldn't find this on wiki or phabricator.
I think it would be a good idea to share it somewhere as it could optimize
the workflow for devs.

I have no strong preferred solution, as long as I am able to store and read
structured data to something that is somewhat
human readable for debugging and or TD tooling.

I didn't consider pugixml, but could also work and is already available. On
the plus side xml has better validation
and querying facilities, on the down side it is xml... :-) Will check with
the admins...

Jeroen.

On Wed, Sep 15, 2021 at 5:19 PM Ray Molenkamp via Bf-committers <
bf-committers at blender.org> wrote:

> 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.
>
> --Ray
>
> [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
> > YAML/JSON.
> >
> > 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
> _______________________________________________
> 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