[
https://issues.apache.org/jira/browse/HDFS-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011089#comment-15011089
]
Bob Hansen commented on HDFS-9117:
----------------------------------
[~wheat9]: thanks for your feedback, and moving the conversation forward
{quote}
bq. Looking at decl.h, consumers don't know what types are supported for get.
Can they get a tcp::endpoint? A float? vector<bool>?
It can be tuned to get a static_assert when they compile the code. They are
left out in the example for brevity.
{quote}
I agree that their code won't compile. Do you disagree with the assertion that
it will be impossible for consumers to know what will and won't work by looking
at the declaration?
I think it's generally better for an API when consumers are able to look at an
interface to know what it does rather than take the stance "try writing against
it and see if you get a compiler error." Do you disagree?
{quote}
bq. How do we distinguish in that API the difference between getting a URI and
getting a string, if both return strings? How do we call getBytes that does
"1K" --> 1024 parsing?
It needs to be wrapped. URI are returned as a URI class instead of a string to
provide information like scheme, port, and hostname.
{quote}
OK for URIs; getBytes?
bq. The argument of better seems subjective.
It absolutely is subjective, but that's what we're called to judge. When there
is a difference of opinion on a subjective matter in the community, how does
the Apache community typically decide the best course of action?
bq. I listed 7 types above. Do you plan to implement the 14 functions required
to support get() and getDefault()?
When implementing 14 simple functions is our largest barrier to landing this
code, I will be an exceedingly happy engineer.
> Config file reader / options classes for libhdfs++
> --------------------------------------------------
>
> Key: HDFS-9117
> URL: https://issues.apache.org/jira/browse/HDFS-9117
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Affects Versions: HDFS-8707
> Reporter: Bob Hansen
> Assignee: Bob Hansen
> Attachments: HDFS-9117.HDFS-8707.001.patch,
> HDFS-9117.HDFS-8707.002.patch, HDFS-9117.HDFS-8707.003.patch,
> HDFS-9117.HDFS-8707.004.patch, HDFS-9117.HDFS-8707.005.patch,
> HDFS-9117.HDFS-8707.006.patch, HDFS-9117.HDFS-8707.008.patch,
> HDFS-9117.HDFS-8707.009.patch, HDFS-9117.HDFS-8707.010.patch,
> HDFS-9117.HDFS-8707.011.patch, HDFS-9117.HDFS-8707.012.patch,
> HDFS-9117.HDFS-8707.013.patch, HDFS-9117.HDFS-8707.014.patch,
> HDFS-9117.HDFS-8707.015.patch, HDFS-9117.HDFS-9288.007.patch
>
>
> For environmental compatability with HDFS installations, libhdfs++ should be
> able to read the configurations from Hadoop XML files and behave in line with
> the Java implementation.
> Most notably, machine names and ports should be readable from Hadoop XML
> configuration files.
> Similarly, an internal Options architecture for libhdfs++ should be developed
> to efficiently transport the configuration information within the system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
