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

Andrew Purtell commented on HBASE-1015:
---------------------------------------

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

Reply via email to