hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: What's going on? Two C++ clients being developed at the moment?
Date Tue, 19 Apr 2016 19:31:03 GMT
So there are a couple of technical topics that we can further discuss and
hopefully come to a conclusion for going forward.

1. Build system. I am in the auto-tools camp, unless there is a very good
reason to use a non-standard tool like Buck / Bazel, etc. Not sure whether
it makes sense to have two different build systems concurrently. Can we do
the main build with make, and create a wrapper with Buck?

2. XML based configuration versus something native. I strongly believe that
we should support standard hbase-site.xml. A lot of tooling in the Hadoop
ecosystem has already been developed for managing and deploying XML based
configurations over the years. Puppet / Chef scripts, Ambari, CM, etc all
understand and support hbase-site.xml. This is also true for hadoop
operators who should be familiar with modifying these files. So it would be
a real pain if we suddenly come up with yet another config format that
requires the operators and tools to learn how to deploy and manage. What if
there are both java clients and C++ clients in the same nodes. How do you
keep two config files in sync? Then there is the issue of
hbase-default.xml. It should be sourced by the config system of C++ client
otherwise how can we default the values? We cannot keep a different version
of the defaults file for the native as well since they will go out of sync
really soon.

Having said that though, it does not mean we should not support other
config formats. We can make the configuration pluggable, so that if needed
other implementations based on properties, etc can be developed.

3. Licenses / Copyright. I think there is already agreement that GPL is a
no-no, and all copyright have to be fixed.

4. Standard Library to use POCO / Folly / Boost / Something else. I would
want us to standardize on something that everybody else uses, like guava.
My understanding is that everybody uses boost, so it is safe to use. I am
not particularly familiar with Folly, but if it has a larger traction that
POCO, if should be better to use.

5. Sync client versus async client. First, we have to differentiate between
async client versus async RPC client. In Java, we have both async RPC
client and sync RPC client. We only have Sync client using async RPC
client.

I did not check the patches in HBASE-14850. Does that have a working async
RPC client yet? If so, can we start with sync client implementation using
the async RPC client? Since we already have the implementation, it will
give us something that can be released and used as an experimental feature.
Then in parallel, we can work on the async client and have it in the same
code base together with the sync client to give users a choice. Then we can
do a further work on trying to get the sync version re-build on top of the
async one once we have confidence with the async client. How does that plan
sound?

6. Interfaces not related to async / sync client or build or standard
library. There is bunch of code in the patches for HBASE-15534 that is not
related to async or sync (get, put, etc). Can we extract those out into a
different patch, and get them committed so that both efforts can use the
same base?

Enis



On Tue, Apr 19, 2016 at 11:20 AM, Andrew Purtell <apurtell@apache.org>
wrote:

> My understanding at this point is someone wants to contribute a C++ client
> which:
> - Is a significant amount of code
> - Is a significant amount of code developed by individuals without an ICLA
> on file at the Foundation
> - Is or was GPL 3 licensed (rights holder can relicense as ASL 2.0, no
> problem)
> - May have copyleft dependencies or generate files with copyleft license
> headers (this would be a showstopper, these have to go)
> - Includes copy-paste code with third party licenses (which might be ok, as
> long as copyright headers are preserved and licensing is compatible)
>
> I would only be comfortable taking this on via the Incubator's IP Clearance
> process (http://incubator.apache.org/ip-clearance/). This should not be
> considered as a roadblock - certainly I don't mean it as such - but instead
> acknowledgement we are dealing with a code grant of uncertain IP
> provenance, so all concerned should be aware of the necessary process for
> getting it in should we want to move forward.
>
>
> On Tue, Apr 19, 2016 at 11:05 AM, Dima Spivak <dspivak@cloudera.com>
> wrote:
>
> > Just to be clear, Apache 2 licensed code CAN be included in GPL 3
> projects,
> > but GPL 3 licensed code CANNOT be included in Apache 2 projects (one-way
> > only). http://www.apache.org/licenses/GPL-compatibility.html provides
> the
> > complete story, I just raised my point early because I’ve personally
> > witnessed the pain that results from people assuming that one FOSS
> license
> > is just like any other.
> >
> > More broadly, I’m assuming I’m not in the minority when I say that until
> > this thread, I had no clue what was going on with these efforts. Easy
> > access to a design doc in a JIRA (if one exists) should always come
> before
> > an 11-page ReviewBoard drop, in my humble opinion.
> >
> > -Dima
> >
> > On Tue, Apr 19, 2016 at 2:26 AM, Priyadharshini Karthikeyan <
> > priya.darshini@hashmapinc.com> wrote:
> >
> > > While generating the configure shell script from configure.ac file,
> > > autoconf by default installs ./install.sh and ./missing. The
> > > ownership/copyright that you are mentioning has come from those default
> > > installs and We have not copied any outside code intentionally. I agree
> > > these dependencies are not suppose to be checked in to the repo.
> > >
> > > Since Apache License version 2.0 is compatible with version 3.0 of the
> > GPL
> > > (GNU Public License), We used GPL for building our hbase C++ client. If
> > it
> > > is not supposed to be used, we will not use it. Thanks for pointing out
> > and
> > > I will address this as high priority.
> > >
> > >
> > >
> > > On 4/19/16, 2:50 AM, "Elliott Clark" <eclark@apache.org> wrote:
> > >
> > > >On Mon, Apr 18, 2016 at 10:59 PM, <vamsi@hashmapinc.com> wrote:
> > > >
> > > >> Whenever we added new source files, the default template injected
> our
> > > >> names into those files.
> > > >>
> > > >
> > > >There are copyrights from:
> > > >
> > > >Copyright (C) 1994 X Consortium
> > > >Copyright (C) 1996-2013 Free Software Foundation, Inc.
> > > >Originally written by Fran,cois Pinard <pinard@iro.umontreal.ca>,
> 1996.
> > > >
> > > >None of those are you. Neither of those are auto generated from
> > eclipse's
> > > >templates.
> > >
> > >
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message