Jake, to follow up on your previous comment re: consensus, after face-to-face conversation I believe the following is our current status.
Agreed: * Strong types with opaque struct pointers * No complete structs in the API/ABI * split shared libraries - one for C, one for C++, one mixed-mode assembly for .net Framework * We will prevent exceptions across the interface boundary. * Namespacing/prefixing. I've included an example of this in the updated RFC. * Pattern and naming conventions for 'new', 'delete', and class methods. Also provided an example in RFC doc * Strong types with opaque struct pointers * No complete structs in the API/ABI This leaves us with just the serialization left undefined. I've added a note about the general approach we intend to take, but a lot of the detail will need to be determined when we get into the work itself, and I consider it beyond the scope of this RFC. Updated RFC is at https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library . Thanks, Blake On Wed, Apr 1, 2020 at 7:06 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > Agreed. It was sort of an inside joke. There used to be a ccache > executable but that was deleted a long time ago. I am in no way advocating > for ccache as the directory or library name. > > > On Apr 1, 2020, at 2:48 PM, Robert Houghton <rhough...@pivotal.io> > wrote: > > > > Quick note: ccache is a C/C++ compiler cache. Examples using 'ccache' as > > the name are confusing. > > > >> On Tue, Mar 31, 2020 at 3:56 PM Jacob Barrett <jbarr...@pivotal.io> > wrote: > >> > >> > >> > >>>> On Mar 31, 2020, at 3:06 PM, Blake Bender <bben...@pivotal.io> wrote: > >>> > >>> We in this instance means the native client team. As far as specific > >>> comments, I'm going to suggest we not go down that road, because this > >> feels > >>> a little more adversarial to me than it needs to be already. > >> > >> Sorry it feels adversarial. From below I think there is a > misunderstanding > >> of my preferences. > >> > >>> Suffice to > >>> say that from my own perspective, in both what you wrote and what I got > >>> from our in-person conversation on Monday, your answer to the general > >>> question "Should the C bindings be part of the native client?" appeared > >> to > >>> be no, thus a separate repository seemed a perfectly reasonable > >>> assumption. I had hoped to do this in the geode-native repo to begin > >> with, > >>> so your assent to this makes life easier. > >> > >> This may be the point of confusion because I have never intended to give > >> the impression that the C-bindings should be separate from the > geode-native > >> repo. My examples even integrate it with the geode-native project. I do > >> believe it should be separate sources and separate includes. I would not > >> want to be doing a C++ project and have C functions clouding my IDE or > >> vice versa. Perhaps that is where the confusion comes from. > >> > >>> As far as my concerns about inefficiency, what I meant is essentially > yes > >>> we have multiple copies of the same code in the release, and this > always > >>> makes me a little uneasy. I've seen a lot of compatibility bugs in my > >>> career having to do with different products having different versions > of > >>> the same code, so my natural inclination is to avoid it when possible. > >>> Having both C++ and C-style functions exported from the same library > >>> doesn't give me any heartburn at all, so simply compiling the C > bindings > >>> into the existing shared library just means one less copy of the code > in > >>> the installation. I fear I am in the minority in this opinion, > however, > >>> and it's not something I'm really doctrinaire about, so I'll defer. > >> I would really like to understand your concerns but I don’t understand > how > >> combining the symbols into a single file resolves the versioning issue? > Can > >> your help me understand what the different produces with different > versions > >> means and how it would apply to this case? > >> > >> If the C and C++ symbols are both exported from the same shared library > >> would you have a common include directory as well or would you spit the > >> includes? I could live with a combine library but not a combined include > >> headers. > >> > >>> So are we good here? I'd like to get the RFC wrapped up and move on to > >>> building this. > >> > >> Do you feel there is a consensus? I feel like there is a lot left that > >> isn’t either in the original RFC, hasn’t been discussed here or is > still a > >> sticking point. You could update the RFC with what we have discussed and > >> see if consensus is reached. > >> > >> Sticking points: > >> * Single or split shared libraries > >> * Single or split includes > >> * Single or split source repository > >> > >> Undefined: > >> * Exception handling (I gave one example but didn’t get feedback or > >> consensus) > >> * Namespacing/Prefixing > >> * Pattern and naming conventions for new, delete and class methods. > >> * Handling of (de)serialization hand off or callbacks into non-C code > >> > >> Agreed: > >> * Strong types with opaque struct pointers > >> * No complete structs in the API/ABI > >> > >> -Jake > >> > >> >
