[
https://issues.apache.org/jira/browse/HDFS-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963963#comment-14963963
]
Bob Hansen commented on HDFS-8766:
----------------------------------
Haohui - thanks for those explicit and actionable items. I'm unsure if you see
all of them as show-stoppers and some as small nits; it would be nice if you
could clarify that when we have the narrow band of Jira to communicate.
1a. While copied code is The Devil, I believe strongly that in the current
state of the code, we should not put forward declarations into a header file
that we don't implement. That will just lead to linker errors later and sad
consumers. Perhaps we should explicitly rename it to "hdfspp.h" to
disambiguate it.
1b. I think we can make forward progress by landing this code with the
integration tests as-is and having a separate Jira to integrate the integration
test functionality with the existing tests. Bringing that scope into this bug
is a major effort, and deserves its own Jira.
2. As we discussed, we will be losing a valuable debugging aid that has sussed
out issues in integration testing already. I don't think we should ship with
this in-place, but I would like to keep it for the short term. Again, let's
make a "Before we merge with trunk" Jira to capture that so we can both reap
the benefits of it during the high-risk portion of our development and not
merge it into trunk.
3. This code won't pass integration test without that fix. As a matter of good
form, it is good to break changes into atomic work units that stand alone, but
as we discussed, we should be flexible during this phase of the development
lifecycle so we don't get held up on issues of form. Can we accept that it's
an improvement and accept?
4. I'm sure this is a minor nit that we can fix as we go, but I hope we're all
on board that this is not a show-stopper.
5. Our plan is to take care of that with HDFS-9144 after this changeset lands.
This is good; that will be better.
The code does need to be re-factored to land on top of HDFS-9207. James - can
you put together a patch that will apply to the current state of the HDFS-8707
branch (and perhaps fix the pread --> Pread renaming while you're there) and
submit a patch that we can land?
Haohui - can we land this patch with your points #1, 2, and 5 captured in new
Jiras?
> Implement a libhdfs(3) compatible API
> -------------------------------------
>
> Key: HDFS-8766
> URL: https://issues.apache.org/jira/browse/HDFS-8766
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: James Clampffer
> Assignee: James Clampffer
> Attachments: HDFS-8766.HDFS-8707.000.patch,
> HDFS-8766.HDFS-8707.001.patch, HDFS-8766.HDFS-8707.002.patch,
> HDFS-8766.HDFS-8707.003.patch, HDFS-8766.HDFS-8707.004.patch,
> HDFS-8766.HDFS-8707.005.patch, HDFS-8766.HDFS-8707.006.patch
>
>
> Add a synchronous API that is compatible with the hdfs.h header used in
> libhdfs and libhdfs3. This will make it possible for projects using
> libhdfs/libhdfs3 to relink against libhdfspp with minimal changes.
> This also provides a pure C interface that can be linked against projects
> that aren't built in C++11 mode for various reasons but use the same
> compiler. It also allows many other programming languages to access
> libhdfspp through builtin FFI interfaces.
> The libhdfs API is very similar to the posix file API which makes it easier
> for programs built using posix filesystem calls to be modified to access HDFS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
