hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6994) libhdfs3 - A native C/C++ HDFS client
Date Wed, 01 Oct 2014 22:30:34 GMT

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

Colin Patrick McCabe commented on HDFS-6994:
--------------------------------------------

bq. Why is this going into the source tree (under contrib, no less!) as libhdfs3?

I agree that libhdfs3 is not a great name.  However, [~aw], the code is currently in a branch.
 It's not going to be part of any release until we find a better name.

Selecting a name is a classic bikeshed argument.  We certainly shouldn't wait on the library
name being resolved to commit the code to a branch.  I do agree that the name should be resolved
before we merge this feature branch, though.

In the spirit of being constructive, I suggest {{libndfs++}} as the name of this library.
 What do you guys think?

bq. Also, why is code getting committed in sub tasks that has clearly been rejected from the
parent? Specifically, HDFS-7011 has the hooks for boost.

The discussion about boost is still ongoing.  Look at the last replies to your comments about
boost by [~wheat9], [~wangzw], and myself.  There is no clear consensus on whether we should
support pre-C\+\+11 compilers via boost.

The code to support pre-C\+\+11 compilers is actually not that large.  It's mostly a few header
files with {{\#ifdef BOOST}}.  Because the same functionality is available through the standard
C\+\+11 library, this discussion doesn't actually have much impact on the design.  And therefore
we can make useful progress while this issue is still being decided.

There are a few things that would help us decide.  One thing is, if we could compile a C\+\+11
library and link it against pre-C\+\+11 code, that would be a clear case for dropping boost
and the other pre-C\+\+11 support.  If we can't do this, then a decision to drop boost is
a de-facto limitation on users of this library to users of ultra-modern systems, which in
practice means most of our users couldn't use it.  There are some indications that this might
be possible for code compiled via llvm that uses {{libc\+\+}}  More research here would really
be helpful.

> libhdfs3 - A native C/C++ HDFS client
> -------------------------------------
>
>                 Key: HDFS-6994
>                 URL: https://issues.apache.org/jira/browse/HDFS-6994
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: hdfs-client
>            Reporter: Zhanwei Wang
>         Attachments: HDFS-6994-rpc-8.patch, HDFS-6994.patch
>
>
> Hi All
> I just got the permission to open source libhdfs3, which is a native C/C++ HDFS client
based on Hadoop RPC protocol and HDFS Data Transfer Protocol.
> libhdfs3 provide the libhdfs style C interface and a C++ interface. Support both HADOOP
RPC version 8 and 9. Support Namenode HA and Kerberos authentication.
> libhdfs3 is currently used by HAWQ of Pivotal
> I'd like to integrate libhdfs3 into HDFS source code to benefit others.
> You can find libhdfs3 code from github
> https://github.com/PivotalRD/libhdfs3
> http://pivotalrd.github.io/libhdfs3/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message