[
https://issues.apache.org/jira/browse/FLINK-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372124#comment-15372124
]
Tzu-Li (Gordon) Tai edited comment on FLINK-4195 at 7/12/16 3:35 AM:
---------------------------------------------------------------------
What about keeping the current constructors that take {{Properties}} config as
argument, but use the reworked configuration class internally? We use the given
{{Properties}} to create the config class. We can also have a new constructor
that takes the reworked configuration class directly, if the user chooses to
use that instead.
A typed configuration class like {{KinesisProducerConfiguration}} will be nice,
and probably easier to handle for the user too. But does having a typed
configuration class mean that we don't need a class like
{{KinesisConfigConstants}} to hold key names anymore? I feel the approach will
somewhat be conflicting with my idea of keeping the {{Properties}}
constructors, so we need to decide which way to go.
was (Author: tzulitai):
What about keeping the current constructors that take {{Properties}} config as
argument, but use the reworked configuration class internally? We use the given
{{Properties}} to create the config class. We can also have a new constructor
that takes the reworked configuration class directly, if the user chooses to
use that instead.
A typed configuration class like {{KinesisProducerConfiguration}} will be nice,
and probably easier to handle for the user too. But does having a typed
configuration class mean that we don't need a class like
{{KinesisConfigConstants}} to hold key names anymore?
> Dedicated Configuration classes for Kinesis Consumer / Producer
> ---------------------------------------------------------------
>
> Key: FLINK-4195
> URL: https://issues.apache.org/jira/browse/FLINK-4195
> Project: Flink
> Issue Type: Sub-task
> Components: Kinesis Connector, Streaming Connectors
> Affects Versions: 1.1.0
> Reporter: Tzu-Li (Gordon) Tai
> Fix For: 1.1.0
>
>
> While fixing FLINK-4170, I feel that configuration and default value setting
> & validation is quite messy and unconsolidated for the current state of the
> code, and will likely become worse as more configs grow for the Kinesis
> connector.
> I propose to have a dedicated configuration class (instead of only Java
> properties) along the lines of Flink's own {{Configuration}}, so that the
> usage pattern is alike. There will be separate configuration classes for
> {{FlinkKinesisConsumerConfig}} and {{FlinkKinesisProducerConfig}}.
> [~uce] [~rmetzger] What do you think? This will break the interface, so if
> we're to change this, I'd prefer to fix it along with FLINK-4170 for Flink
> 1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
