You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2013/01/17 19:00:26 UTC

[jira] [Comment Edited] (HBASE-1015) pure C and C++ client libraries

    [ 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