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. 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.
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. So are we good here? I'd like to get the RFC wrapped up and move on to building this. Thanks, Blake On Tue, Mar 31, 2020 at 2:03 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > > > > On Mar 31, 2020, at 1:48 PM, Matthew Reddington <mredding...@pivotal.io> > wrote: > > > > A separate repo is our interpretation of the comments generated by this > RFC. > > Can you please quote specific statements that you interpreted to suggest > separate repositories. I would like to understand where this interpretation > comes from. > > > We consider these separate projects and that they should be organized as > such. > > Who is we? Does the we reflect the owners of the comments you are > referencing above? > > In the end Geode is a single project in the eyes of ASF. > > -Jake > >