Thanks Larry. I'll have that PR for a first pass submitted in a few hours. The only one that's come up so far is the geterror() mechanism (returning a string, which means caching it with a thread_local in the C layer) but I'll write more about that later.
Cheers, Anders On Thu, 22 Oct 2020 at 17:13, Larry Gritz <[email protected]> wrote: > I just want to make sure you know... > > If you see something in the APIs that is "too C++" in the sense that it is > extremely reliant on very C++-specific idioms, not only in expression but > also conceptually, and therefore difficult to map to C or the way any other > language would see things, then by all means make suggestions or even add > something new on the C++ API to make the C wrappers easier. Don't feel like > the C++ API is 100% set in stone and a sacred item that can't be changed. > Your design space can extend into the existing interfaces if there are ways > to improve them. > > > On Oct 20, 2020, at 8:33 PM, Anders Langlands <[email protected]> > wrote: > > Sounds good Scott. Once I’ve sketched out something and we all agree on a > general approach let’s split the bindings into small chunks we can each > tackle and PR piece wise and do the same for the Rust crate? > > On Wed, 21 Oct 2020 at 14:49, Scott Wilson <[email protected]> wrote: > >> That works for me. I'll start contributing bindings once Anders sends in >> the first PR. >> >> On Tue, Oct 20, 2020 at 5:39 PM Larry Gritz <[email protected]> wrote: >> >>> On Oct 20, 2020, at 1:56 PM, Anders Langlands <[email protected]> >>> wrote: >>> >>> Ok so then what I think I’ll do is port the C part of my rust crate over >>> to oiio proper, implementing just enough to add a simple round-trip test, >>> is load an image, add an attribute to the header, write it out as an exr. >>> Then I’ll make a PR so you can comment. Sound good? >>> >>> >>> Awesome. >>> >>> And I would recommend that we approach the C bindings piece by piece. >>> I'm a fan of breaking it up into many small PRs so they can each be >>> reviewed quickly, one class at a time. Start with the easy ones and along >>> the way I'm sure we'll hash out the design issues and have a consensus by >>> the time we get to the big hairy classes. If we try to do it all at once, >>> we could end up going down the wrong road and only discover when in the >>> middle of reviewing and integrating an enormous amount of code that we >>> wished we had made some different basic decision. >>> >>> -- lg >>> >>> > -- > Larry Gritz > [email protected] > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
