[
https://issues.apache.org/jira/browse/KAFKA-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869759#comment-17869759
]
Matthias J. Sax commented on KAFKA-17215:
-----------------------------------------
I cannot help with creating a Confluence account, however, your account should
have been created according to
https://issues.apache.org/jira/browse/INFRA-25451?focusedCommentId=17867582&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17867582
?
If your account was not created, please follow up on the INFRA ticket. If you
account was created (you should have gotten an email), please share your
account name so we can grant you write access to the wiki.
About this ticket. I just want to give you a heads up, that it might be
controversial, and there is a fair chance that a KIP will be rejected. Cleanup
work like this implies noise to Kafka Streams users, and there is often push
back on work like this as "not worth" it (cf the PR about `StreamsConfig`
linked in the ticket description – there was also critical comments about this
POC PR...)
> Remove get-prefix for all getters
> ---------------------------------
>
> Key: KAFKA-17215
> URL: https://issues.apache.org/jira/browse/KAFKA-17215
> Project: Kafka
> Issue Type: Improvement
> Components: streams, streams-test-utils
> Reporter: Matthias J. Sax
> Priority: Minor
> Labels: needs-kip
>
> Kafka traditionally does not use a `get` prefix for getter methods. However,
> for multiple public interfaces, we don't follow this common pattern, but
> actually have a get-prefix.
> We might want to clean this up. The upcoming 4.0 release might be a good
> opportunity to deprecate existing methods and add them back with the
> "correct" name.
> We should maybe also do multiple smaller KIPs instead of just one big KIP. We
> do know of the following
> * StreamsConfig (getMainConsumerConfigs, getRestoreConsumerConfigs,
> getGlobalConsumerConfigs, getProducerConfigs, getAdminConfigs, getClientTags,
> getKafkaClientSupplier – for some of these, we might even consider to remove
> them; it's questionable if it makes sense to have them in the public API (cf
> [https://github.com/apache/kafka/pull/14548)] – we should also consider
> https://issues.apache.org/jira/browse/KAFKA-16945 for this work)
> * TopologyConfig (getTaskConfig)
> * KafkaClientSupplier (getAdmin, getProducer, getConsumer,
> getRestoreConsumer, getGlobalConsumer)
> * Contexts (maybe not worth it... we might deprecate the whole class soon):
> ** ProcessorContext (getStateStore)
> ** MockProcessorContext (getStateStore)
> ** MockProcessorContext#{color:#172b4d}CapturedPunctuator (getIntervalMs,
> getType, getPunctuator),{color}
> * api.ProcessingContext (getStateStore)
> ** api.FixedKeyProcessorContext (getStateStore)
> ** api.MockProcessorContext (getStateStore, getStateStoreContext)
> ** api.MockProcessorContext#{color:#172b4d}CapturedPunctuator (getInterval,
> getType, getPunctuator){color}
> * StateStore (getPosition)
>
> * IQv2: officially an evolving API (maybe we can rename in 4.0 directly w/o
> deprecation period, but might be nasty...)
> ** KeyQuery (getKey)
> ** Position (getTopics, getPartitionPositions)
> ** QueryResult (getExecutionInfo, getPosition, getFailureReason,
> getFailureMessage, getResult)
> ** RangeQuery (getLowerBound, getUpperBound)
> ** StateQueryRequest (getStoreName, getPositionBound, getQuery,
> getPartitions)
> ** StateQueryResult (getPartitionResults, getOnlyPartitionResult,
> getGlobalResult, getPosition)
> ** WindowKeyQuery (getKey, getTimeFrom, getTimeTo,
> ** WindowRangeQuery (getKey, getTimeFrom, getTimeTo)
>
> * TopologyTestDriver (getAllStateStores, getStateStore, getKeyValueStore,
> getTimestampedKeyValueStore, getVersionedKeyValueStore, getWindowStore,
> getTimestampedWindowStore, getSessionStore)
> * TestOutputTopic (getQueueSize)
> * TestRecord (getHeaders, getKey, getValue, getRecordTime)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
