hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-1015) pure C and C++ client libraries
Date Thu, 17 Jan 2013 18:00:26 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556412#comment-13556412
] 

Andrew Purtell edited comment on HBASE-1015 at 1/17/13 5:59 PM:
----------------------------------------------------------------

bq. I don't think the thrift core makes sense anymore, considering protobuf. 

I would agree. The embedded thrift servers in the regionservers were an experiment at FB that
they've backed away from. THRIFT-1620 is open with no implementation available.

bq. I think an HBase client library implemented in C is a mandatory feature for a database
approaching 1.0 release.

The PB work is not finished.

The scope of building a C client is not just the transport, it's also duplicating or replacing
all of the functionality of the fat Java client.

Various discussions about "native client" usually end with the notion of a Grand Unified Client
Project: lighter weight async client, perhaps asynchbase itself or in the mold of it, talking
PB to the cluster, with a sync API layered on top. It might be straightforward to build a
C++ analogue to asynchbase with std::async (don't know enough about C++11 to say for sure).
That does not provide an answer for C folks though.
                
      was (Author: apurtell):
    bq. I don't think the thrift core makes sense anymore, considering protobuf. 

I would agree. The embedded thrift servers in the regionservers were an experiment at FB that
they've backed away from. THRIFT-1620 is open with no implementation available.

bq. I think an HBase client library implemented in C is a mandatory feature for a database
approaching 1.0 release.

The PB work is not finished.

The scope of building a C client is not just the transport, it's also duplicating or replacing
all of the functionality of the fat Java client.

Various discussions I have had about "native client" usually end with the notion of a Grand
Unified Client Project: lighter weight async client, perhaps asynchbase itself or in the mold
of it, talking PB to the cluster, with a sync API layered on top. It might be straightforward
to build a C++ analogue to asynchbase with std::async (don't know enough about C++11 to say
for sure).
                  
> pure C and C++ client libraries
> -------------------------------
>
>                 Key: HBASE-1015
>                 URL: https://issues.apache.org/jira/browse/HBASE-1015
>             Project: HBase
>          Issue Type: New Feature
>          Components: Client
>    Affects Versions: 0.20.6
>            Reporter: Andrew Purtell
>            Priority: Minor
>
> If via HBASE-794 first class support for talking via Thrift directly to HMaster and HRS
is available, then pure C and C++ client libraries are possible. 
> The C client library would wrap a Thrift core. 
> The C++ client library can provide a class hierarchy quite close to o.a.h.h.client and,
ideally, identical semantics. It  should be just a wrapper around the C API, for economy.
> Internally to my employer there is a lot of resistance to HBase because many dev teams
have a strong C/C++ bias. The real issue however is really client side integration, not a
fundamental objection. (What runs server side and how it is managed is a secondary consideration.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message