Hey Matthias, Thanks for the suggestions. I agree with all of them. They all make sense to me. I updated the KIP accordingly.
Bests, Alieh On Thu, Feb 19, 2026 at 8:33 PM Matthias J. Sax <[email protected]> wrote: > Thanks for the KIP. Great follow up to KIP-1271. > > > > Nit: The `DSL_STORE_TYPE_DOC` should be `private` and I also think we > can improve the wording -- but that's more of am impl detail, not really > critical for the KIP itself. > > How about: > > "Controls the state store type used by the DSL store supplier (see > config 'dsl.store.suppliers.class'). 'default' uses timestamped stores. > 'headers' uses the headers-aware stores." > > > > MJS1: Should we deprecate the existing `DslKeyValueParams(final String > name, final boolean isTimestamped)` constructor, and make the newly > introduced "type" a mandatory parameter? (Cf MJS2 below) > > > > MJS2: Should we add new enum `DslStoreType` with DEFAULT and HEADERS > value, and change the constructor > > from > - DslKeyValueParams(final String name, final boolean isTimestamped, > final boolean isHeadersEnabled) > > to > - DslKeyValueParams(final String name, final DslStoreType storeType) > > This would more align to the newly added String config (and the KIP > calls out that we did not want to add a boolean config, what makes sense > to me), and would subsume the existing `isTimestamped` parameter on the > existing constructor which we could remove (Cf MJS1) > > [We have a similar thing for `group.protocol` config.] > > > If yes, wondering if we should also deprecate `isTimestamped()` and not > add `headersEnabled()` but instead add `storeType()` getter? > > Similar for window/session Dsl*Parameter classes. > > > > -Matthias > > > On 2/18/26 3:30 AM, Alieh Saeedi via dev wrote: > > Hi all, > > > > I’d like to start a discussion on a new KIP, KIP-1285: DSL Opt-in Support > > for Header-Aware State Stores. > > > > KIP-1271 introduced headers-aware state stores in Kafka Streams. KIP-1285 > > proposes adding corresponding DSL-level opt-in support, so that DSL > > applications can take advantage of these headers-aware stores while > keeping > > existing applications and topologies unchanged by default. > > > > You can find the KIP here: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1285%3A+DSL+Opt-in+Support+for+Header-Aware+State+Stores > > > > Feedback would be greatly appreciated. > > > > Best, > > Alieh > > > >
