Hi Chia-Ping, Thank you for the KIP and apologies for missing it earlier.
A minor comment. The SPI is currently used exclusively for the ConsoleProducer. However, it exposes high-level methods which hint at it being a generic component. What is the actual scope of the SPI inside the Kafka codebase? Is it planned to be re-used in other tools? Or is this interface used (not implemented) outside of the ConsoleProducer? Thanks, Alexandre Le sam. 18 févr. 2023 à 19:02, Chia-Ping Tsai <chia7...@apache.org> a écrit : > > > > On 2023/02/18 08:44:05 Tom Bentley wrote: > > Hi Chia-Ping, > > > > To be honest the stateful version, setting an input stream once using the > > `readFrom(InputStream)` method and then repeatedly asking for the next > > record using a parameterless `readRecord()`, seems a bit more natural to me > > than `readRecord(InputStream inputStream)` being called repeatedly with (I > > assume) the same input stream. I think the contract is simpler to describe > > and understand. > > I prefer readRecord() also. It is a trade-off between having `Configurable` > interface and having a parameterless readRecord(). If the `Configurable` is > not required, I'd like to revert to readRecord(). WDYT? > > > > > It's worth thinking about how implementers might have to read bytes from > > the stream to discover the end of one record and the start of the next. > > Unless we've guaranteed that the input stream supports mark and reset then > > they have to buffer the initial bytes of the next record that they've just > > read from the stream so that they can use them when called next time. So I > > think RecordReaders are (in general) inherently stateful and therefore it > > seems harmless for them to also have the input stream itself as some of > > that state. > > you are right. As the input stream is keyboard input, it would be hard to > expect the number of bytes for one record. >
