Re: RFC: Add C Bindings to Geode Native Client

[Robert Houghton <rh...@pivotal.io>]

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 <jb...@pivotal.io> wrote:

>
>
> > On Mar 31, 2020, at 3:06 PM, Blake Bender <bb...@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
>
>

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender <bb...@pivotal.io>]

Hello everyone,

I neglected to put an end date on this RFC, but it's been open for 2+ weeks
now, and I believe we're close to (at?) consensus, so I would like to close
it out and move on ASAP.  If you still have anything urgent to add, please
reply here and let's hash it out.  All other things being equal, I'll
summarize anything left that needs it and move the RFC to 'Active' status
Monday morning (PDT).

Thanks,

Blake

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender <bb...@pivotal.io>]

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 <jb...@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 <rh...@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 <jb...@pivotal.io>
> wrote:
> >>
> >>
> >>
> >>>> On Mar 31, 2020, at 3:06 PM, Blake Bender <bb...@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
> >>
> >>
>

Re: RFC: Add C Bindings to Geode Native Client

[Jacob Barrett <jb...@pivotal.io>]

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 <rh...@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 <jb...@pivotal.io> wrote:
>> 
>> 
>> 
>>>> On Mar 31, 2020, at 3:06 PM, Blake Bender <bb...@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
>> 
>>