Hi Ray, It's been quiet here for a while. What's the status for this KIP?
Thanks! Bill On Mon, Sep 9, 2024 at 9:51 AM Ray McDermott <r...@mcdermott.be> wrote: > It was on pause during the summer - vacations took priority. > > I will check your feedback this week and give an update. > > Ray > > > On Thursday, 22 August 2024 at 20:20, Matthias J. Sax <mj...@apache.org> > wrote: > > > What is the status of this KIP? > > > > On 7/30/24 7:36 PM, Matthias J. Sax wrote: > > > > > Thanks a lot for the KIP > > > > > > Ray > > > > > > ! > > > > > > It seems to be a good improvement to make using KS with Clojure more > > > seamless. > > > > > > However, I am not 100% sure if all listed interfaces make sense? > > > > > > (100) GlobalKTable: it's basically a sibling to `KStream`, and `KTable` > > > interfaces, but users would never implemented it, and thus I think it > > > won't make much sense to add the annotation. Playing devils advocate, > it > > > could even be "harmful" as it might provide a wrong signal to users > that > > > this interface would be intended to be implemented by them. > > > > > > (200) NamedOperation: this is some helper interface that user also > won't > > > need to implement. I am less worried about being harmful (as I am for > > > GlobalKTable), but I also don't see much of an advantage. > > > > > > (300) TransformerSupplier and ValueTransformerSupplier: both are going > > > to be deprecate with 4.0, which is only a side cleanup anyway. Both can > > > only be used with `KStream.transform()`, `.flatTransform()`, > > > `.transformValues()` and `.flatTransformValues()` and all four method > > > will be removed in 4.0 rending both interface practically useless. -- > No > > > damage to include them, but also not useful. > > > > > > (400) ProcessorSupplier and Processor: there is currently two > interfaces > > > with each name, the old and already deprecated interfaces > > > `...processor.Processor[Supplier]` and the new > > > `...processor.api.Processor[Supplier]`. The KIP should be explicit and > > > say `api.Proceccor[Supplier]` as only the new interfaces have > annotation > > > already, but not the old ones. - The old interfaces do also not need to > > > be updated IMHO, as will we remove both with 4.0, too. > > > > > > (410) There is also two interfaces `...processor.ProcessorContext` and > > > `...processor.api.ProcessorContext`. Both are still in used, and thus > > > the KIP should mention both explicitly. > > > > > > (500) I am not sure if the KIP need to explicitly list all interface it > > > does not update... It's a long list and it might be easier to read the > > > KIP if omitted? > > > > > > (600) There is some other interface/abstract-classes which might > benefit > > > from the annotation, too: > > > > > > - org.apache.kafka.streams.errors: > > > > > > DeserializationExceptionHandler (does not qualify now, but we could > > > include it in the KIP and file a follow up ticket for the future to add > > > it, when we remove the deprecated method? -- This would avoid the need > > > for another KIP in the future) > > > StreamsUncaughtExceptionHandler > > > > > > - org.apache.kafka.streams.processor.api: > > > > > > ContextualFixedKeyProcessor > > > ContextualProcessor > > > > > > - org.apache.kafka.streams.processor: > > > > > > CommitCallback > > > Punctuator > > > StateRestoreCallback > > > StreamPartitioner (there is already a open PR to remove the > > > deprecate method so it will qualify in 4.0 release) > > > TimestampExtractor > > > TopicNameExtractor > > > > > > -Matthias > > > > > > On 7/29/24 12:47 AM, Ray McDermott wrote: > > > > > > > These annotations assist with clarifying the purpose of the > interface, > > > > as well as assisting interop with non-Java JVM languages. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1072%3A+Add+@FunctionalInterface+annotation+to+Kafka+Streams+SAM+methods > > > > > > > > Comments welcome > > > > > > > > Thanks > > > > > > > > Ray >
