Re: JSON/YAML parsing in CPP

Jeroen Bakker via Bf-committers <[email protected]>
Newsgroups gmane.comp.video.blender.devel
Message-ID <CADcDVT1jWEsaKCQ08TU-jFRf5FMY7KyH=837uxOBNHkuwr5cOg@mail.gmail.com>
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 <
[email protected]> 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
> > [email protected]
> > List details, subscription details or unsubscribe:
> > https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> [email protected]
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[email protected]
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.