[
https://issues.apache.org/jira/browse/KAFKA-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923524#comment-13923524
]
Jay Kreps commented on KAFKA-1299:
----------------------------------
I agree. Perhaps we can make a ProducerOptions and ConsumerOptions trait to
share some of these. I think a hybrid strategy is actually best. The problem
with not exposing any of the client configs as command line arguments is the
tool becomes hugely painful to use (basically you have to keep going back and
forth to find the magical property names on the website, you can't just look at
the usage).
With the new config classes this is actually solvable in multiple ways. We
could actually automagically generate an option for each config (with help). Or
we could print out the list of configs with the usage but use --property x=y.
> Standardize configs across tools
> --------------------------------
>
> Key: KAFKA-1299
> URL: https://issues.apache.org/jira/browse/KAFKA-1299
> Project: Kafka
> Issue Type: Improvement
> Components: tools
> Reporter: Neha Narkhede
> Labels: usability
>
> We have quite a few tools that have a set of options relevant to the tool but
> then also need a way to expose the specific properties of either a consumer
> and a producer. It makes the tool pretty unwieldy to use if we clutter the
> tool options with the individual producer/consumer options. What's more, this
> approach makes it difficult to maintain the tools with every new config we
> add on our clients.
> Currently, the approach ReplayLogProducer follows is to only expose the
> options related to the tool and leave the producer/consumer specific options
> to be accepted through the generic --property option.
> There might be another way to reduce the clutter but it will be good to
> standardize one convention across all tools
--
This message was sent by Atlassian JIRA
(v6.2#6252)
