After reading John's latest response, I agree as well.
+1(binding)
-Bill
On Tue, Feb 26, 2019 at 9:09 PM Matthias J. Sax <matth...@confluent.io>
wrote:
> Florian,
>
> Thanks for updating the KIP.
>
> I missed the missing `static` on `Suppressed#withName()` and I agree
> with John and Guozhang.
>
> Don't have any further comments. And thanks for splitting the PR!
>
>
> @Guozhang: there is already a VOTE thread.
>
>
>
> -Matthias
>
> On 2/26/19 3:26 PM, Guozhang Wang wrote:
> > Bill, John, thanks for your comments.
> >
> > I agree with John that we can leave Suppressed to not have a static
> method
> > `as` for now since it is not useful at the moment. Assuming that is
> agreed
> > on, I think we can move on to the voting process.
> >
> >
> > Guozhang
> >
> > On Tue, Feb 26, 2019 at 2:56 PM John Roesler <j...@confluent.io> wrote:
> >
> >> Thanks for the feedback, Bill.
> >>
> >> It might be a good idea to hold of on adding the static method to
> >> Suppressed for now...
> >>
> >> Unlike the other operator/config-class pairs, `suppress` has no
> "default"
> >> mode. That is, there is no `KTable.suppress()` method with no arguments.
> >> So, when using it, you must either pick `untilWindowCloses` or
> >> `untilTimeLimit`, and you can also only pick one of those.
> >>
> >> The current `withName` method is an optional way to add a name to the
> >> Suppressed config.
> >>
> >> Adding `Suppressed.as(name)` as another static factory method seems to
> have
> >> some real downsides at the moment:
> >> * `suppress(Suppressed.as(name))` is an invalid config, so we can
> either go
> >> to extra lengths with an intermediate builder class just to store the
> name,
> >> or lose the compile-time guarantee that you actually pick one of the
> >> suppression types, and instead just check at run time.
> >> * The two config choices are currently static factory methods, so adding
> >> `as(name)` obligates us to also add chained versions of
> `untilWindowCloses`
> >> and `untilTimeLimit`. This opens up a new can of worms to name the
> chained
> >> methods, and it also creates more ambiguity in the API, since there are
> >> then multiple ways to say the same thing.
> >>
> >> Maybe in the future, if there's some automatic default configuration for
> >> suppression, then we can add `as(name)`, but from where I'm sitting
> right
> >> now, it seems to have no real upside and a few downsides.
> >>
> >> So, to summarize, I would propose to basically leave `Suppressed`'s
> >> interface alone and just extend the new `NamedOperation`.
> >>
> >> WDYT?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Tue, Feb 26, 2019 at 9:18 AM Bill Bejeck <bbej...@gmail.com> wrote:
> >>
> >>> Hi Florian,
> >>>
> >>> Thanks for the update to the KIP.
> >>>
> >>> As for changing the name for "Suppressed#withName", I believe we can
> >> update
> >>> the table in KIP to say "Suppressed#as" as the KIP states that:
> >>>
> >>>>> In addition, we propose to add a new static method with the following
> >>> signature to each of those class *as(final String processorName).*
> >>>
> >>> where Suppressed is one of the classes listed.
> >>>
> >>> So once we make that minor update to the KIP, we can start the vote.
> >>>
> >>> Thanks!
> >>> Bill
> >>>
> >>>
> >>>
> >>> On Mon, Feb 25, 2019 at 5:24 AM Florian Hussonnois <
> >> fhussonn...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Matthias, Bill,
> >>>>
> >>>> I've updated the KIP with your last feedbacks. However, you have
> >>> suggested
> >>>> to rename : `Suppressed#withName(String)`
> >>>> withName is not a static method like Joined.named was. withName method
> >> is
> >>>> part of the new interface NameOperation.
> >>>>
> >>>> In addition, I've split the PR in 5 commits so that it will be much
> >>> easier
> >>>> to review.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Le jeu. 21 févr. 2019 à 23:54, Bill Bejeck <bbej...@gmail.com> a
> >> écrit :
> >>>>
> >>>>> Hi Florian,
> >>>>>
> >>>>> Overall the KIP LGTM. Once you've addressed the final comments from
> >>>>> Matthias I think we can put this up for a vote.
> >>>>>
> >>>>> Thanks,
> >>>>> Bill
> >>>>>
> >>>>> On Wed, Feb 20, 2019 at 9:42 PM Matthias J. Sax <
> >> matth...@confluent.io
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Florian,
> >>>>>>
> >>>>>> thanks for updating the KIP (and no worries for late reply -- 2.2
> >>>>>> release kept us busy anyway...). Overall LGTM.
> >>>>>>
> >>>>>> Just some nits:
> >>>>>>
> >>>>>>
> >>>>>> KStream-Table:
> >>>>>>
> >>>>>> Do we need to list the existing stream-globalTable join methods in
> >>> the
> >>>>>> first table (thought it should only contain new/changing methods).
> >>>>>>
> >>>>>> typo: `join(GlobalKTbale, KeyValueMapper, ValueJoiner, Named)`
> >>>>>>
> >>>>>> `leftJoin(GlobalKTable, KeyValueMapper, ValueJoiner)` is missing
> >> the
> >>>> new
> >>>>>> `Named` parameter.
> >>>>>>
> >>>>>> `static Joined#named(final String name)`
> >>>>>> -> should be `#as(...)` instead of `named(...)`
> >>>>>>
> >>>>>> flatTransform() is missing (cf. KIP-313)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> KTable-table:
> >>>>>>
> >>>>>> `Suppressed#withName(String)`
> >>>>>> -> should we change this to `#as(...)` too (similar to `named()`)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -Matthias
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/25/19 9:49 AM, Matthias J. Sax wrote:
> >>>>>>> I was reading the KIP again, and there are still some open
> >> question
> >>>> and
> >>>>>>> inconsistencies:
> >>>>>>>
> >>>>>>> For example for `KGroupedStream#count(Named)` the KIP says, that
> >>> only
> >>>>>>> the processor will be named, while the state store name will be
> >>>> `PREFIX
> >>>>>>> + COUNT` (ie, an auto-generated name). Additionally, for
> >>>>>>> `KGroupedStream#count(Named, Materialized)` the processor will be
> >>>> named
> >>>>>>> according to `Named` and the store will be named according to
> >>>>>>> `Materialized.as()`. So far so good. It implies that naming the
> >>>>>>> processor and naming the store are independent. (This pattern is
> >>>>> applied
> >>>>>>> to all aggregation functions, for KStream and KTable).
> >>>>>>>
> >>>>>>> However, for `KTable#filter(Predicate, Named)` the KIP says, the
> >>>>>>> processor name and the store name are set. This sound wrong (ie,
> >>>>>>> inconsistent with the first paragraph from above), because there
> >> is
> >>>>> also
> >>>>>>> `KTable#filter(Predicate, Named, Materialized)`. Also note, for
> >> the
> >>>>>>> first operator, the store might not be materialized to at all.
> >>> (This
> >>>>>>> issue is there for all KTable operators -- stateless and
> >> stateful).
> >>>>>>>
> >>>>>>> Finally, there is the following statement in the KIP:
> >>>>>>>
> >>>>>>>> Also, note that for all methods accepting a Materialized
> >> argument,
> >>>> if
> >>>>>> no state store named is provided then the node named will be used
> >> to
> >>>>>> generate a one. The state store name will be the node name suffixed
> >>>> with
> >>>>>> "-table".
> >>>>>>>
> >>>>>>>
> >>>>>>> This contradict the non-naming of stores from the very beginning.
> >>>>>>>
> >>>>>>>
> >>>>>>> Also, the KIP still contains the question about
> >> `join(GlobalKTable,
> >>>>>>> KeyValueMapper, ValueJoiner)` and `leftJoin(GlobalKTable,
> >>>>>>> KeyValueMapper, ValueJoiner)`. I think a consistent approach
> >> would
> >>> be
> >>>>> to
> >>>>>>> add one overload each that takes a `Named` parameter.
> >>>>>>>
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>>
> >>>>>>> -Matthias
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1/17/19 2:56 PM, Bill Bejeck wrote:
> >>>>>>>> +1 for me on Guozhang's proposal for changes to Joined.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Bill
> >>>>>>>>
> >>>>>>>> On Thu, Jan 17, 2019 at 5:55 PM Matthias J. Sax <
> >>>>> matth...@confluent.io>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Thanks for all the follow up comments!
> >>>>>>>>>
> >>>>>>>>> As I mentioned earlier, I am ok with adding overloads instead
> >> of
> >>>>> using
> >>>>>>>>> Materialized to specify the processor name. Seems this is what
> >>> the
> >>>>>>>>> majority of people prefers.
> >>>>>>>>>
> >>>>>>>>> I am also +1 on Guozhang's suggestion to deprecate `static
> >>>>>>>>> Joined#named()` and replace it with `static Joined#as` for
> >>>>> consistency
> >>>>>>>>> and to deprecate getter `Joined#name()` for removal and
> >> introduce
> >>>>>>>>> `JoinedInternal` to access the name.
> >>>>>>>>>
> >>>>>>>>> @Guozhang: the vote is already up :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -Matthias
> >>>>>>>>>
> >>>>>>>>> On 1/17/19 2:45 PM, Guozhang Wang wrote:
> >>>>>>>>>> Wow that's a lot of discussions in 6 days! :) Just catching up
> >>> and
> >>>>>>>>> sharing
> >>>>>>>>>> my two cents here:
> >>>>>>>>>>
> >>>>>>>>>> 1. Materialized: I'm inclined to not let Materialized
> >> extending
> >>>>> Named
> >>>>>> and
> >>>>>>>>>> add the overload as well. All the rationales have been very
> >> well
> >>>>>>>>> summarized
> >>>>>>>>>> before. Just to emphasize on John's points: Materialized is
> >>>>>> considered as
> >>>>>>>>>> the control object being leveraged by the optimization
> >> framework
> >>>> to
> >>>>>>>>>> determine if the state store should be physically materialized
> >>> or
> >>>>>> not. So
> >>>>>>>>>> let's say if the user does not want to query the store (hence
> >> it
> >>>> can
> >>>>>> just
> >>>>>>>>>> be locally materialized), but still want to name the
> >> processor,
> >>>> they
> >>>>>> need
> >>>>>>>>>> to do either
> >>>>>> "count(Materialized.as(null).withName("processorName"));" or
> >>>>>>>>>> "count(Named.as("processorName"));" and neither of it is a bit
> >>>> hard
> >>>>> to
> >>>>>>>>>> educate to users, and hence it looks that an overload function
> >>>> with
> >>>>>> two
> >>>>>>>>>> parameters are easier to understand.
> >>>>>>>>>>
> >>>>>>>>>> 2. As for `NamedOperation`: I've left a comment about it
> >> before,
> >>>>> i.e.
> >>>>>> "1)
> >>>>>>>>>> Regarding the interface / function name, I'd propose we call
> >> the
> >>>>>>>>> interface
> >>>>>>>>>> `NamedOperation` which would be implemented by Produced /
> >>>> Consumed /
> >>>>>>>>>> Printed / Joined / Grouped / Suppressed (note I intentionally
> >>>>> exclude
> >>>>>>>>>> Materialized here since its semantics is quite), and have the
> >>>>> default
> >>>>>>>>> class
> >>>>>>>>>> that implements `NamedOperation` as `Named`, which would be
> >> used
> >>>> in
> >>>>>> our
> >>>>>>>>>> adding overload functions. The main reason is to have
> >>> consistency
> >>>> in
> >>>>>>>>>> naming." And I think I'm on the same page with John with his
> >>> more
> >>>>>>>>> detailed
> >>>>>>>>>> proposal.
> >>>>>>>>>>
> >>>>>>>>>> 3. As for `Joined`: I actually would suggest we bite the
> >> bullet
> >>>> and
> >>>>>>>>> remove
> >>>>>>>>>> it as well, because we are trying to fix some inconsistencies
> >> in
> >>>>> this
> >>>>>> KIP
> >>>>>>>>>> anyways (or is that not agreed upon yet?), my thoughts were
> >> that
> >>>> we
> >>>>>> will
> >>>>>>>>>> have the following breaking renamings as below:
> >>>>>>>>>>
> >>>>>>>>>> 3.a) static Joined#named() -> Joined#as()
> >>>>>>>>>> 3.b) Joined#name() -> "deleted"
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I also think that we can start the voting thread asap since we
> >>> are
> >>>>>>>>>> achieving to an consensus and the KIP deadline is approaching.
> >>> The
> >>>>>> wiki
> >>>>>>>>>> page itself may still need to be updated though with the API
> >>>>> breaking
> >>>>>>>>>> changes above.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Guozhang
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Jan 17, 2019 at 1:43 PM Florian Hussonnois <
> >>>>>>>>> fhussonn...@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Sorry, I've sent my previous mail to quickly. Unlike the
> >>>> Consumed,
> >>>>>>>>> Produced
> >>>>>>>>>>> and Grouped classes, the Joined class does have getter
> >> methods.
> >>>> So
> >>>>> I
> >>>>>>>>>>> propose to keep the name() method only for this class.
> >>>>>>>>>>> For other classes the name will be accessible through
> >>> XXXInternal
> >>>>>>>>> classes.
> >>>>>>>>>>>
> >>>>>>>>>>> Le jeu. 17 janv. 2019 à 22:39, John Roesler <
> >> j...@confluent.io
> >>>>
> >>>> a
> >>>>>>>>> écrit :
> >>>>>>>>>>>
> >>>>>>>>>>>> Just to chime in regarding NamedInternal. That was my bad
> >>> mental
> >>>>>> model
> >>>>>>>>> to
> >>>>>>>>>>>> blame. It is indeed coercion, not casting. Even more
> >> relevant,
> >>>> I'm
> >>>>>> not
> >>>>>>>>> a
> >>>>>>>>>>>> fan of the XInternal pattern, but it is the pattern we have.
> >>> It
> >>>>>> would
> >>>>>>>>> be
> >>>>>>>>>>>> worse to start carving out exceptions.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So I agree that we should have:
> >>>>>>>>>>>> * `NamedOperation` interface, declaring only the
> >>>>> `withName(String)`
> >>>>>>>>>>> setter
> >>>>>>>>>>>> member
> >>>>>>>>>>>> * `Named implements NamedOperation` class with a protected
> >>>> `name`
> >>>>>>>>> field,
> >>>>>>>>>>>> set by the `withName` setter (and also other config objects
> >>>> would
> >>>>> do
> >>>>>>>>> the
> >>>>>>>>>>>> same, e.g., `Grouped implements NamedOperation`)
> >>>>>>>>>>>> * `NamedInternal extends Named` class with a public (but
> >>>>> internally
> >>>>>>>>>>>> targeted) `name()` getter to expose the name to the topology
> >>>>>> builder.
> >>>>>>>>>>>> Likewise all the other config classes that implement
> >>>>> NamedOperation
> >>>>>>>>> would
> >>>>>>>>>>>> expose a `name()` getter for the same purpose. It's not in
> >> the
> >>>>>> public
> >>>>>>>>>>> API,
> >>>>>>>>>>>> but we should take care to make sure the getter method has
> >> the
> >>>>> same
> >>>>>>>>> name
> >>>>>>>>>>>> everywhere for minimum confusion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks, everyone!
> >>>>>>>>>>>> -John
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Jan 17, 2019 at 12:09 PM Bill Bejeck <
> >>> bbej...@gmail.com
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I'm getting caught up with the current state of this KIP.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I agree that the question on what to do with overloads is a
> >>>>>> difficult
> >>>>>>>>>>> one
> >>>>>>>>>>>>> to answer.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Both John and Matthias have laid out their thoughts
> >>> thoroughly,
> >>>>> and
> >>>>>>>>> the
> >>>>>>>>>>>>> points made by both resonate with me.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've spent some time thinking about this, and while I have
> >> a
> >>>>>> problem
> >>>>>>>>>>> with
> >>>>>>>>>>>>> adding overloaded methods, I can't quite get comfortable
> >> with
> >>>> the
> >>>>>>>>>>> notion
> >>>>>>>>>>>> of
> >>>>>>>>>>>>> Materialized naming the processing node. For me, it comes
> >>> down
> >>>>> to
> >>>>>> the
> >>>>>>>>>>>> fact
> >>>>>>>>>>>>> that Materialized is used to configure the state store for
> >> an
> >>>>>>>>>>> individual
> >>>>>>>>>>>>> processing node and knows nothing of the operation itself.
> >> So
> >>>>> I'll
> >>>>>> go
> >>>>>>>>>>>> with
> >>>>>>>>>>>>> adding the Named overload to methods taking a Materialized
> >>> by a
> >>>>>> narrow
> >>>>>>>>>>>>> margin.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As for the name method, I agree with Matthias that it's not
> >>>>>> consistent
> >>>>>>>>>>>> with
> >>>>>>>>>>>>> the approach we've taken so far whether for better or
> >> worse,
> >>>> but
> >>>>> to
> >>>>>>>>>>> quote
> >>>>>>>>>>>>> Matthias, "that ship has sailed." IMHO adding the method
> >> for
> >>>>>> making
> >>>>>>>>>>>>> testing easier doesn't justify it, as there are ways to get
> >>> the
> >>>>>> name
> >>>>>>>>>>> via
> >>>>>>>>>>>>> NamedInternal class.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Just my 2 cents.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> Bill
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Jan 16, 2019 at 5:40 PM Matthias J. Sax <
> >>>>>>>>> matth...@confluent.io
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for the details John.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> While I understand your argument that it is no optimal to
> >>> use
> >>>>>>>>>>>>>> `Materialized` to set the processor name, I still slightly
> >>>>> prefer
> >>>>>>>>>>> this
> >>>>>>>>>>>>>> option, because adding more overloads seems to be even
> >> worse
> >>>> to
> >>>>>> me.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But I would also not block this KIP if the majority of
> >>> people
> >>>>>> prefer
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> add overloads instead of extending `Materialized`.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> However, I cannot follow your argument about
> >>>>>> `NamedOperation#name()`
> >>>>>>>>>>>>>> getter method. So far, all configuration classes don't
> >> have
> >>>>>> getters
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> it seems to be inconsistent to add a single one now. We
> >> also
> >>>>> don't
> >>>>>>>>>>> need
> >>>>>>>>>>>>>> any cast IMHO, as we would use the same construct as we do
> >>> for
> >>>>> all
> >>>>>>>>>>>> other
> >>>>>>>>>>>>>> config classed via `NamedInternal` to access the name:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> final String name = new NamedInternal(named).name();
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Maybe, it would have been better to add getters from the
> >>>>>> beginning on
> >>>>>>>>>>>>>> (even if I think it was the right decision to not add
> >>>> getters).
> >>>>>>>>>>>> However,
> >>>>>>>>>>>>>> this ship have sailed and if we want to add getters to
> >> avoid
> >>>> the
> >>>>>>>>>>>>>> `XxxInternal()` construct, we should do it for all classes
> >>> --
> >>>>>>>>>>> however,
> >>>>>>>>>>>>>> what would a user gain if we do this? It would just be a
> >> lot
> >>>> of
> >>>>>>>>>>> "noise"
> >>>>>>>>>>>>>> IMHO.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> @Florian: I would suggest to start a VOTE if you want to
> >> get
> >>>>> this
> >>>>>>>>>>> into
> >>>>>>>>>>>>>> 2.2 release. The open questions seem to be minor and I
> >> think
> >>>> we
> >>>>>> can
> >>>>>>>>>>>>>> resolve them in parallel to the vote.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 1/16/19 12:59 PM, John Roesler wrote:
> >>>>>>>>>>>>>>> Hi Matthias,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> One thing that we discussed earlier was to avoid creating
> >>>>>> ambiguity
> >>>>>>>>>>>> by
> >>>>>>>>>>>>>>> conflating config objects that configure an operation
> >> (like
> >>>>>>>>>>> Grouped)
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> config objects that configure an aspect of the operation
> >>>> (like
> >>>>>>>>>>>>>>> Materialized).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It is natural for the Grouped config to extend Named, as
> >>>> doing
> >>>>> so
> >>>>>>>>>>>>>> indicates
> >>>>>>>>>>>>>>> that grouping operations can be named (I.e., the name
> >>> applies
> >>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>> operation itself, which in turn makes it reasonable to
> >> use
> >>>> the
> >>>>>>>>>>>>>> operation's
> >>>>>>>>>>>>>>> name as a component in the related processors' and
> >> topics'
> >>>>>> names).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But what would it mean for Materialized to extend Named?
> >>>>>>>>>>> Materialized
> >>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>> configures the materialization of an operation's result,
> >>> not
> >>>>> the
> >>>>>>>>>>>>>> operation
> >>>>>>>>>>>>>>> itself, so I guess it would mean the name applies to the
> >>>> result
> >>>>>> of
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> operation? It doesn't really work.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Adding config objects to the DSL was an attempt to avoid
> >>>>> overload
> >>>>>>>>>>>> bloat
> >>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>> more aspects of operations need to be configured.
> >>>>>>>>>>>>>>> However, we made a mistake with Materialized, since (as
> >>>> noted)
> >>>>> it
> >>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>> configure the operation itself, but just one aspect of
> >> it.
> >>>>>>>>>>>>>>> We basically bagged a bunch of parameters into one,
> >> without
> >>>>>> solving
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> problem structurally, and this is the result:
> >>>>>>>>>>>>>>> As soon as we need to configure a *different* aspect of
> >> the
> >>>>>>>>>>>> operation,
> >>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> again need to add a new overload, and the cycle begins
> >>> again.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The proper solution here is to add an eponymous config
> >>> object
> >>>>> to
> >>>>>>>>>>> each
> >>>>>>>>>>>>>>> stateful operation, one which mixes in or composes the
> >>>>>> Materialized
> >>>>>>>>>>>>>> aspect
> >>>>>>>>>>>>>>> config and the Named aspect config. But this is a large
> >> API
> >>>>>> change,
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> decided on the middle ground of just adding Named as an
> >>>>> optional
> >>>>>>>>>>>>>> parameter
> >>>>>>>>>>>>>>> via new overloads for now.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A similar compromise was to go ahead and add a Named
> >>> overload
> >>>>>>>>>>>> directly
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> all the operators that currently have no config object.
> >>>>>>>>>>>>>>> Again, the proper thing would be to add a new config
> >> class
> >>>> for
> >>>>>> each
> >>>>>>>>>>>>>>> individual operation, but it seemed like a drastic
> >> change.
> >>>>>>>>>>>>>>> We basically said that right now, we don't think we'll
> >> ever
> >>>>> need
> >>>>>> to
> >>>>>>>>>>>>>>> configure another aspect of those operators than the
> >> name,
> >>>> and
> >>>>>>>>>>> we're
> >>>>>>>>>>>>>>> acknowledging that if we do, we'll have to created a
> >> small
> >>>> mess
> >>>>>> to
> >>>>>>>>>>>>> clean
> >>>>>>>>>>>>>> up.
> >>>>>>>>>>>>>>> It's really just a generalization of the same problem
> >> with
> >>>>>>>>>>>> Materialized
> >>>>>>>>>>>>>>> operations.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> To answer your question about the Named interface:
> >>>>>>>>>>>>>>> The primary reason is that Named is an aspect that is
> >> meant
> >>>> to
> >>>>> be
> >>>>>>>>>>>> mixed
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> with other config objects.
> >>>>>>>>>>>>>>> For example, Grouped can extend Named.
> >>>>>>>>>>>>>>> If we followed the pattern you've referenced, we would
> >>> have a
> >>>>>>>>>>> public
> >>>>>>>>>>>>>>> interface Named with only the setter and a private class
> >>>>>>>>>>>> NamedInternal
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> the setter and getter.
> >>>>>>>>>>>>>>> But would Grouped be a subclass of NamedInternal?
> >>>>>>>>>>>>>>> Then, we could only have one kind of aspect mixin, since
> >>> Java
> >>>>>>>>>>> doesn't
> >>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>> multiple class inheritance, or we'd have to decide if the
> >>>> next
> >>>>>>>>>>> thing
> >>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>> be a superclass of Named or a subclass of Named and a
> >>>>> superclass
> >>>>>> of
> >>>>>>>>>>>>>> Grouped.
> >>>>>>>>>>>>>>> Plus, in the implementation, instead of just casting
> >>> Grouped
> >>>> to
> >>>>>>>>>>>>>>> GroupedInternal (which is already unclean design), we'd
> >>> also
> >>>> be
> >>>>>>>>>>>> casting
> >>>>>>>>>>>>>>> Grouped to NamedInternal, which is super confusing.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It's far cleaner all around just to use the type system
> >>> "the
> >>>>>> right
> >>>>>>>>>>>>> way",
> >>>>>>>>>>>>>>> which is what we've proposed.
> >>>>>>>>>>>>>>> Any config class can mix in the Named aspect, and it
> >>>> inherits a
> >>>>>>>>>>>>> contract
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> supply both the setter and the getter.
> >>>>>>>>>>>>>>> Our implementation can actually avoid any casting in this
> >>>>> usage,
> >>>>>>>>>>>> since
> >>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> can just call grouped.name() to get the name, instead of
> >>>>>> something
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>>> ((NamedInternal) grouped).name().
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Plus, what harm does it do to let people get back the
> >>>>>> configuration
> >>>>>>>>>>>>>>> property that they *just set* on the config object?
> >>>>>>>>>>>>>>> It doesn't break encapsulation.
> >>>>>>>>>>>>>>> It would certainly make writing tests a lot easier for
> >>>>> everyone.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> All around, I would advocate for moving toward this
> >> design
> >>>> for
> >>>>>> all
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> config interfaces, as I've previously demonstrated how
> >>> we've
> >>>>> made
> >>>>>>>>>>> an
> >>>>>>>>>>>>>>> intractable mess out of the window config hierarchy by
> >>> trying
> >>>>> to
> >>>>>> be
> >>>>>>>>>>>>>> clever
> >>>>>>>>>>>>>>> and hiding the getters.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I hope this helps,
> >>>>>>>>>>>>>>> -John
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Jan 16, 2019 at 12:59 AM Matthias J. Sax <
> >>>>>>>>>>>>> matth...@confluent.io>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> While I understand that it should be possible to specify
> >>>> store
> >>>>>>>>>>> name
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> processor name independent from each other, it's still
> >>>> unclear
> >>>>>> to
> >>>>>>>>>>>> me,
> >>>>>>>>>>>>>>>> why we cannot use the `Materialized` parameter to
> >> specify
> >>>> the
> >>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>> name:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> // only set the node name
> >>>>>>>>>>>>>>>>> #count(Named.as("processorName"));
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> // only set the store name
> >>>>>>>>>>>>>>>>> #count(Materialized.as("storeName"));
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> // set both
> >>>>>>>>>>>>>>>>>
> >>>>> #count(Materialized.as("storeName").withName("processorName"));
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This this case, it might be good to rename `withName` to
> >>>>>>>>>>>>>>>> `withProcessorName` to avoid confusion with the store
> >>> name.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> However, why do we need this:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> #count(Materialized.as("storeName"),
> >>>>>> Named.as("processorName"));
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would prefer to not add this overload.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Strictly, we could also avoid `#count(Named)`, and set
> >> the
> >>>>>>>>>>> processor
> >>>>>>>>>>>>>>>> name only via:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >> #count(Materialized.as(null).withName("processorName"));
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I admit, it's a little clumsy, but would save us one
> >> more
> >>>>>>>>>>> overload.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> One more comment that I forgot last time: why do we add
> >>> the
> >>>>>> getter
> >>>>>>>>>>>>>>>> `Named#name()`? All other configuration classes only
> >>> define
> >>>>>>>>>>> setters
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> we add getters only in the internal implementation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 1/13/19 4:22 AM, Florian Hussonnois wrote:
> >>>>>>>>>>>>>>>>> Hi Matthias,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The reason for overloading the methods with
> >> Materialized
> >>>>>>>>>>> parameter
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> regarding the semantic of this class.
> >>>>>>>>>>>>>>>>> The Materialized class allow to name a queryable store.
> >>> if
> >>>> a
> >>>>>> name
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>> set
> >>>>>>>>>>>>>>>>> then it will be used both to name the state-store and
> >>> the
> >>>>>>>>>>>>>>>> changelog-topic.
> >>>>>>>>>>>>>>>>> If no name is given, then the provided Named will be
> >>> used.
> >>>>>>>>>>>>>>>>> This allow to name the operation without having a
> >>> queriable
> >>>>>>>>>>> store.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So if my analysis is correct, we will end up with :
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Generated | Named
> >> |
> >>>>>> Joined /
> >>>>>>>>>>>>>>>> Grouped
> >>>>>>>>>>>>>>>>> | Materialized
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> Node | X |
> >> X
> >>>>>> |
> >>>>>>>>>>>> X
> >>>>>>>>>>>>>>>>> |
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> Repartition Topic | X |
> >>>> |
> >>>>>> X
> >>>>>>>>>>>>>>>>> |
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> Queryable Store | |
> >>>> |
> >>>>>>>>>>>>>>>>> | X
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> State store | X | X
> >>>> |
> >>>>>>>>>>> X
> >>>>>>>>>>>>>>>>> | X
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> Changelog Topic | X | X |
> >>>>> X
> >>>>>>>>>>>>>>>>> | X
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> -------------------------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Le dim. 13 janv. 2019 à 03:23, Matthias J. Sax <
> >>>>>>>>>>>>> matth...@confluent.io>
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Just catching up on this KIP again.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> One nit. The KIP says:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> In addition, the generated names have a few
> >>> disadvantages
> >>>>> to
> >>>>>>>>>>>>>> guarantee
> >>>>>>>>>>>>>>>>>> topology compatibilities. In fact, adding a new
> >>> operator,
> >>>>>> using
> >>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> third-library doing some optimization to remove some
> >>>>> operators
> >>>>>>>>>>> or
> >>>>>>>>>>>>>>>> upgrading
> >>>>>>>>>>>>>>>>>> to a new KafkaStreams version with internal API
> >> changes
> >>>> may
> >>>>>>>>>>>> changed
> >>>>>>>>>>>>>>>> suffix
> >>>>>>>>>>>>>>>>>> indexing for a large amount of the processor names.
> >> This
> >>>>> will
> >>>>>> in
> >>>>>>>>>>>>> turn
> >>>>>>>>>>>>>>>>>> change the internal state store names, as well as
> >>> internal
> >>>>>> topic
> >>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>> well.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> This is not true any longer (I guess it was true, when
> >>> the
> >>>>> KIP
> >>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>> initially proposed), because all
> >> stores/internal-topics
> >>>> can
> >>>>> be
> >>>>>>>>>>>> named
> >>>>>>>>>>>>>>>>>> since 2.1 release. I would suggest to remove the
> >>>> paragraph.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Overall, I like the Named/NamedOperation design.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> What is unclear to me thought is, why we need new
> >>>> overloads
> >>>>>> for
> >>>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>>>> that accept `Materialized`. To be more precise, I
> >> think
> >>> it
> >>>>>> make
> >>>>>>>>>>>>> sense
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> add an overload that only takes `Named`, but not one
> >>> that
> >>>>>> takes
> >>>>>>>>>>>> both
> >>>>>>>>>>>>>>>>>> `Named` and `Materialized`. For example:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> KGroupedStream#count() // exists
> >>>>>>>>>>>>>>>>>> KGroupedStream#count(Materialized) // exits
> >>>>>>>>>>>>>>>>>> KGroupedStream#count(Named) // added (makes sense to
> >> me)
> >>>>>>>>>>>>>>>>>> KGroupedStream#count(Named, Materialized) // added --
> >>> why?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I would prefer to use `Materialized` to name the
> >>> processor
> >>>>> for
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>> case, too. Can you elaborate on the motivation?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 1/11/19 3:39 PM, Florian Hussonnois wrote:
> >>>>>>>>>>>>>>>>>>> Hi Guozhang,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I have updated the PR as well as the KIP. I should
> >> add
> >>>> more
> >>>>>>>>>>> unit
> >>>>>>>>>>>>>> tests
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> covers all new methods.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> However, I still have one test in failure. The reason
> >>> is
> >>>>> that
> >>>>>>>>>>>> using
> >>>>>>>>>>>>>>>>>>> Joined.name() in both potential repartition topic and
> >>>>>> processor
> >>>>>>>>>>>>> nodes
> >>>>>>>>>>>>>>>>>> leads
> >>>>>>>>>>>>>>>>>>> to topology-incompatible.
> >>>>>>>>>>>>>>>>>>> How should we deal with that ?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Le jeu. 10 janv. 2019 à 01:21, Guozhang Wang <
> >>>>>>>>>>> wangg...@gmail.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hello Florian,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Just checking if have read about my previous email
> >> and
> >>>> if
> >>>>>> you
> >>>>>>>>>>>> feel
> >>>>>>>>>>>>>>>> happy
> >>>>>>>>>>>>>>>>>>>> about it. We have the 2.2 KIP freeze deadline at
> >> 24th
> >>>> this
> >>>>>>>>>>>> month,
> >>>>>>>>>>>>>>>> while
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> PR itself is getting quite close. So it'll be great
> >> if
> >>>> we
> >>>>>> can
> >>>>>>>>>>>> get
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> agreement on it and get it into 2.2.0 release.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 2:39 PM Guozhang Wang <
> >>>>>>>>>>>> wangg...@gmail.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Hi Florian / John,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Just wanted to throw a couple minor thoughts on the
> >>>>> current
> >>>>>>>>>>>>>> proposal:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 1) Regarding the interface / function name, I'd
> >>> propose
> >>>>> we
> >>>>>>>>>>> call
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> interface `NamedOperation` which would be
> >> implemented
> >>>> by
> >>>>>>>>>>>>> Produced /
> >>>>>>>>>>>>>>>>>>>>> Consumed / Printed / Joined / Grouped / Suppressed
> >>>> (note
> >>>>> I
> >>>>>>>>>>>>>>>>>> intentionally
> >>>>>>>>>>>>>>>>>>>>> exclude Materialized here since its semantics is
> >>>> quite),
> >>>>>> and
> >>>>>>>>>>>> have
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> default class that implements `NamedOperation` as
> >>>>> `Named`,
> >>>>>>>>>>>> which
> >>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>> used in our adding overload functions. The main
> >>> reason
> >>>> is
> >>>>>> to
> >>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>> consistency in naming.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2) As a minor tweak, I think it's better to use
> >>>>>> Joined.name()
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>> both
> >>>>>>>>>>>>>>>>>> its
> >>>>>>>>>>>>>>>>>>>>> possibly generate repartition topic, as well as the
> >>> map
> >>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>> group-by (currently this name is only used for the
> >>>>>>>>>>> repartition
> >>>>>>>>>>>>>>>> topic).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Florian: if you think this proposal makes sense,
> >>> please
> >>>>>> feel
> >>>>>>>>>>>> free
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>> ahead and update the PR; after we made a first pass
> >>> on
> >>>> it
> >>>>>> and
> >>>>>>>>>>>>> feels
> >>>>>>>>>>>>>>>>>>>>> confident about it, we can go ahead with the VOTING
> >>>>>> process.
> >>>>>>>>>>>>> About
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> implementation of 2) above, this may be out of your
> >>>>>>>>>>>>> implementation
> >>>>>>>>>>>>>>>>>> scope,
> >>>>>>>>>>>>>>>>>>>>> so feel free to leave it out side your PR while
> >> Bill
> >>>> who
> >>>>>>>>>>>>> originally
> >>>>>>>>>>>>>>>>>> worked
> >>>>>>>>>>>>>>>>>>>>> on the Grouped KIP can make a follow-up PR for it.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Dec 14, 2018 at 9:43 PM Guozhang Wang <
> >>>>>>>>>>>>> wangg...@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hello Florian,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Really appreciate you for your patience.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I know that we've discussed about the approach to
> >>>> adding
> >>>>>>>>>>>>>> overloaded
> >>>>>>>>>>>>>>>>>>>>>> functions and rejected it early on. But looking
> >>> deeper
> >>>>>> into
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> current PR
> >>>>>>>>>>>>>>>>>>>>>> I realized that this approach has a danger of
> >> great
> >>>> API
> >>>>>>>>>>>>> confusions
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>>>>>>>> (I tried to explain my thoughts in the PR, but it
> >>> was
> >>>>> not
> >>>>>>>>>>> very
> >>>>>>>>>>>>>>>> clear)
> >>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>>> the basic idea is that, today we already have a
> >> few
> >>>>>> existing
> >>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>> classes including Grouped, Joined, Suppressed that
> >>>> allow
> >>>>>>>>>>> users
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> specify
> >>>>>>>>>>>>>>>>>>>>>> serdes etc, while also a "name" which can then be
> >>> used
> >>>>> to
> >>>>>>>>>>>> define
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>> processor name / internal topic names in the
> >>> topology
> >>>>> (the
> >>>>>>>>>>>>> static
> >>>>>>>>>>>>>>>>>> function
> >>>>>>>>>>>>>>>>>>>>>> names are not consistent, which I think we should
> >>> fix
> >>>> as
> >>>>>>>>>>>> well).
> >>>>>>>>>>>>>> And
> >>>>>>>>>>>>>>>>>> Named
> >>>>>>>>>>>>>>>>>>>>>> interface, by extending the lambda function
> >>> interfaces
> >>>>>> like
> >>>>>>>>>>>>>>>>>> ValueJoiner /
> >>>>>>>>>>>>>>>>>>>>>> Predicate etc opens the door for another way to
> >>>> specify
> >>>>>> the
> >>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>> again.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So in order to achieve consistency, we are left
> >> with
> >>>>>>>>>>> generally
> >>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>>>>>>>> options:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 1) only allow users to specify names via the
> >> lambda
> >>>>>>>>>>> interfaces
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>> extends Named interface. This means we'd better
> >>> remove
> >>>>> the
> >>>>>>>>>>>>> naming
> >>>>>>>>>>>>>>>>>> mechanism
> >>>>>>>>>>>>>>>>>>>>>> from the existing control objects to keep
> >>> consistency.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 2) only allow users to specify names via control
> >>>>> classes,
> >>>>>>>>>>> and
> >>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>> introduce a new class (Named) for those which do
> >> not
> >>>>> have
> >>>>>>>>>>> one
> >>>>>>>>>>>>> yet
> >>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>> leads to the overloaded functions.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I did a quick count on the num.of overloaded
> >>>> functions,
> >>>>>> and
> >>>>>>>>>>>>>> summing
> >>>>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>>>>> KTable (8) / KStream (15) / KGroupedStream (6) /
> >>>>>>>>>>> KGroupedTable
> >>>>>>>>>>>>>> (6) /
> >>>>>>>>>>>>>>>>>>>>>> TimeWindowedKStream (6) / SessionWindowedKStream
> >> (6)
> >>>> we
> >>>>>> got
> >>>>>>>>>>>>> about
> >>>>>>>>>>>>>> 47
> >>>>>>>>>>>>>>>>>>>>>> overloaded functions (our guess was pretty close!)
> >>> --
> >>>>> note
> >>>>>>>>>>>> this
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> based on
> >>>>>>>>>>>>>>>>>>>>>> John's proposal that we can let existing Grouped /
> >>>>> Joined
> >>>>>> to
> >>>>>>>>>>>>>> extend
> >>>>>>>>>>>>>>>>>> Named
> >>>>>>>>>>>>>>>>>>>>>> and hence we only need overloaded functions with a
> >>>>> default
> >>>>>>>>>>>>>>>>>> NamedOperation
> >>>>>>>>>>>>>>>>>>>>>> for those operators that do not have a control
> >>> classes
> >>>>>>>>>>>> already.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Thinking about this approach I feel it is not too
> >>> bad
> >>>>>>>>>>> compared
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>> either 1) above, which would require us to
> >> deprecate
> >>>> lot
> >>>>>> of
> >>>>>>>>>>>>> public
> >>>>>>>>>>>>>>>>>>>>>> functions around name(), or having a mixed
> >> mechanism
> >>>> for
> >>>>>>>>>>>> naming,
> >>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>> could lead to very confusing behavior to users.
> >>>>>>>>>>> Additionally,
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> most
> >>>>>>>>>>>>>>>>>>>>>> users who would only want to specify the names for
> >>>> those
> >>>>>>>>>>>>> stateful
> >>>>>>>>>>>>>>>>>>>>>> operations which have internal topics / state
> >> stores
> >>>> and
> >>>>>>>>>>> hence
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>>>> keen to upgrade compatibility, those added
> >> overloads
> >>>>> would
> >>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> not-often
> >>>>>>>>>>>>>>>>>>>>>> used functions for them anyways. And by letting
> >>>> existing
> >>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>> classes to
> >>>>>>>>>>>>>>>>>>>>>> extend Named, we can have a unified method name
> >> for
> >>>>> static
> >>>>>>>>>>>>>>>>>> constructor as
> >>>>>>>>>>>>>>>>>>>>>> well.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 14, 2018 at 10:24 AM John Roesler <
> >>>>>>>>>>>>> j...@confluent.io>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Sorry about the run-around of rejecting the
> >>> original
> >>>>>>>>>>>> proposal,
> >>>>>>>>>>>>>>>>>>>>>>> only to return to it later on. Hopefully, it's
> >> more
> >>>>>>>>>>>> encouraging
> >>>>>>>>>>>>>>>>>>>>>>> than frustrating that we're coming around to your
> >>>>> initial
> >>>>>>>>>>> way
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> thinking.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>>>>>>>>> -John
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Thu, Dec 13, 2018 at 4:28 PM Florian
> >> Hussonnois
> >>> <
> >>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Thanks again. I agree with your propositions.
> >>>>>>>>>>>>>>>>>>>>>>>> Also IMHO, overloading all methods (filter, map)
> >>> to
> >>>>>>>>>>> accept a
> >>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>>>> object seems to provide a more natural
> >> development
> >>>>>>>>>>>> experience
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> users.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Actually, this was the first proposition for
> >> this
> >>>> KIP,
> >>>>>> but
> >>>>>>>>>>>> we
> >>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>> rejected
> >>>>>>>>>>>>>>>>>>>>>>>> it because this solution led to adding a lot of
> >>> new
> >>>>>>>>>>> methods.
> >>>>>>>>>>>>>>>>>>>>>>>> As you mentioned it, the API has evolve since
> >> the
> >>>>>> creation
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> KIP -
> >>>>>>>>>>>>>>>>>>>>>>>> some existing control objects already allow to
> >>>>> customize
> >>>>>>>>>>>>>> internal
> >>>>>>>>>>>>>>>>>>>>>>> names. We
> >>>>>>>>>>>>>>>>>>>>>>>> should so keep on that strategy.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> If everyone is OK with that, I will update the
> >> KIP
> >>>> and
> >>>>>> the
> >>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>>>>>> accordingly;
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 13 déc. 2018 à 18:08, John Roesler <
> >>>>>>>>>>>> j...@confluent.io
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Hi again, all,
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Matthias, I agree with you.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Florian, thanks for your response.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I think your proposal is the best way to
> >> address
> >>>> the
> >>>>>> ask
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> hiding
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>> name() getter. But I'd like to question that
> >> ask
> >>>> and
> >>>>>>>>>>>> instead
> >>>>>>>>>>>>>>>>>>>>>>> propose that
> >>>>>>>>>>>>>>>>>>>>>>>>> we just make the name() getter part of the
> >> public
> >>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> The desire to "hide" the getters causes a lot
> >> of
> >>>>>>>>>>> complexity
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> our
> >>>>>>>>>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>>>>> base, and it will become completely impractical
> >>>> with
> >>>>>> the
> >>>>>>>>>>>>> mixin
> >>>>>>>>>>>>>>>>>>>>>>> strategy
> >>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>> Named.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> If we were to switch strategies back to mixing
> >>>> Named
> >>>>> in
> >>>>>>>>>>> to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>>>>> objects rather than the functions, then the
> >> path
> >>>>>> forward
> >>>>>>>>>>>>>> becomes
> >>>>>>>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>>> clear.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On the other hand, it seems harmless for anyone
> >>> who
> >>>>>> wants
> >>>>>>>>>>>> to
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>> able to
> >>>>>>>>>>>>>>>>>>>>>>>>> query the name from a control object after
> >>> setting
> >>>>> it,
> >>>>>> so
> >>>>>>>>>>>> my
> >>>>>>>>>>>>>> vote
> >>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>> simply to keep the Named interface as:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> public interface Named<T extends Named<T>> {
> >>>>>>>>>>>>>>>>>>>>>>>>> String name();
> >>>>>>>>>>>>>>>>>>>>>>>>> T withName(String name);
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Under this proposal, we only mix Named in to
> >> the
> >>>>>> control
> >>>>>>>>>>>>>> objects,
> >>>>>>>>>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>>>>> means we have no need of default
> >> implementations
> >>>>>> anymore
> >>>>>>>>>>>>>> (because
> >>>>>>>>>>>>>>>>>>>>>>> we can
> >>>>>>>>>>>>>>>>>>>>>>>>> update all the control objects concurrently
> >> with
> >>>>> adding
> >>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> interface to
> >>>>>>>>>>>>>>>>>>>>>>>>> them).
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> This does hinge on switching over to a
> >>>>>>>>>>> control-object-only
> >>>>>>>>>>>>>>>>>> strategy,
> >>>>>>>>>>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>>>>> introduces the need to add about 50 new control
> >>>>> object
> >>>>>>>>>>>>> classes,
> >>>>>>>>>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>> only serve to implement Named. As a middle
> >>> ground,
> >>>>>> maybe
> >>>>>>>>>>> we
> >>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>>>>>>> one generic control object class, like:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> public class NamedOperation implements
> >>>>>>>>>>>> Named<NamedOperation>
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>> private final String name;
> >>>>>>>>>>>>>>>>>>>>>>>>> private NamedOperation(final String name) {
> >>>>>> this.name
> >>>>>>>>>>> =
> >>>>>>>>>>>>>> name;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>> public static NamedOperation name(final
> >> String
> >>>>> name)
> >>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>> return new NamedOperation(name);
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>> public String name() { return name; }
> >>>>>>>>>>>>>>>>>>>>>>>>> public NamedOperation withName(final String
> >>>> name) {
> >>>>>>>>>>>>>>>>>>>>>>>>> return new NamedOperation(name);
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> And then, we'd add overloads for all the
> >> methods
> >>>> that
> >>>>>>>>>>> don't
> >>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>>>>> objects already (for example, filter() ):
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> // existing
> >>>>>>>>>>>>>>>>>>>>>>>>> KStream<K, V> filter(Predicate<? super K, ?
> >> super
> >>>> V>
> >>>>>>>>>>>>>> predicate);
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> // new
> >>>>>>>>>>>>>>>>>>>>>>>>> KStream<K, V> filter(Predicate<? super K, ?
> >> super
> >>>> V>
> >>>>>>>>>>>>> predicate,
> >>>>>>>>>>>>>>>>>>>>>>>>> NamedOperation named);
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Additionally, in regard to Matthias's point
> >> about
> >>>>>>>>>>> existing
> >>>>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>>>> objects
> >>>>>>>>>>>>>>>>>>>>>>>>> with naming semantics, they would extend Named
> >>> (but
> >>>>> not
> >>>>>>>>>>>>>>>>>>>>>>> NamedOperation)
> >>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>> uniformity.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> You provided a good approach to hide the getter
> >>>> with
> >>>>>> your
> >>>>>>>>>>>>>>>>>>>>>>> SettableName
> >>>>>>>>>>>>>>>>>>>>>>>>> class; I think what you proposed is the only
> >> way
> >>> we
> >>>>>> could
> >>>>>>>>>>>>> hide
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> name.
> >>>>>>>>>>>>>>>>>>>>>>>>> In the end, though, it's a lot of complexity
> >>> added
> >>>>>>>>>>> (control
> >>>>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>>>>>> class
> >>>>>>>>>>>>>>>>>>>>>>>>> hierarchy, inheritance, mutable state, internal
> >>>>>> casting)
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> something of
> >>>>>>>>>>>>>>>>>>>>>>>>> dubious value: to be able to hide the name from
> >>>>> someone
> >>>>>>>>>>>>> *after
> >>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>>> themselves have set it*.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Although it'll be a pain, perhaps Matthias's
> >>>>> suggestion
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> enumerate all
> >>>>>>>>>>>>>>>>>>>>>>>>> the API methods is the best way to be sure we
> >> all
> >>>>> agree
> >>>>>>>>>>> on
> >>>>>>>>>>>>>> what's
> >>>>>>>>>>>>>>>>>>>>>>> going
> >>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> happen.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks again for wrangling with this issue,
> >>>>>>>>>>>>>>>>>>>>>>>>> -John
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Dec 13, 2018 at 9:03 AM Matthias J.
> >> Sax <
> >>>>>>>>>>>>>>>>>>>>>>> matth...@confluent.io>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Just catching up on this discussion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> My overall personal take is, that I am not a
> >> big
> >>>> fan
> >>>>>> of
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>> `Named` that is used as a factory. I would
> >>> rather
> >>>>>> prefer
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> control object parameter to all methods that
> >>> don't
> >>>>>> have
> >>>>>>>>>>>> one
> >>>>>>>>>>>>>> yet.
> >>>>>>>>>>>>>>>>>>>>>>> This
> >>>>>>>>>>>>>>>>>>>>>>>>>> KIP was started a while ago, and we added new
> >>>> naming
> >>>>>>>>>>>>>>>> capabilities
> >>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> meantime. Guozhang's example in the PR comment
> >>>> about
> >>>>>>>>>>>> naming
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>> stream-stream join shows, that we might end up
> >>> in
> >>>> a
> >>>>>>>>>>>>> confusion
> >>>>>>>>>>>>>>>>>>>>>>> situation
> >>>>>>>>>>>>>>>>>>>>>>>>>> for users if we use `Named`. Also, in 2.1,
> >> user
> >>>> can
> >>>>>>>>>>>> already
> >>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>>> repartition-/changelog-topics and stores.
> >> Thus,
> >>>>>> KIP-307
> >>>>>>>>>>>>> boils
> >>>>>>>>>>>>>>>>>>>>>>> down to
> >>>>>>>>>>>>>>>>>>>>>>>>>> provide non-functional naming?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Hence, for all methods that allow to specify
> >>> names
> >>>>>>>>>>>> already,
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>> don't see
> >>>>>>>>>>>>>>>>>>>>>>>>>> any reason to change them, but use the
> >> existing
> >>>> API
> >>>>> to
> >>>>>>>>>>>> also
> >>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> processor(s) instead of allowing uses to
> >>> specify a
> >>>>> new
> >>>>>>>>>>>> name.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> About the inconsistency in method naming. I
> >>> agree,
> >>>>>> that
> >>>>>>>>>>>> `as`
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>>>>>>>>>>>> generic and maybe not the best choice.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I think it might be helpful, to have a table
> >>>>> overview
> >>>>>> in
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> KIP,
> >>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>> list all existing static/non-static methods
> >> that
> >>>>> allow
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>>> specify
> >>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> name, plus a columns with the new suggested
> >>> naming
> >>>>> for
> >>>>>>>>>>>> those
> >>>>>>>>>>>>>>>>>>>>>>> methods?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 12/12/18 12:45 AM, Florian Hussonnois
> >> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you very much for your feedbacks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Currently, there is still lot of discussions
> >>>>>> regarding
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> Named
> >>>>>>>>>>>>>>>>>>>>>>>>>> interface.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On the one hand we should provided
> >> consistency
> >>>> over
> >>>>>> the
> >>>>>>>>>>>>>> stream
> >>>>>>>>>>>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the other hand we should not break the
> >> semantic
> >>>> as
> >>>>>> John
> >>>>>>>>>>>>> point
> >>>>>>>>>>>>>>>>>>>>>>> it up.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang, I'm sorry, but I'm little bit
> >>> confused,
> >>>>>>>>>>> maybe I
> >>>>>>>>>>>>>>>> missed
> >>>>>>>>>>>>>>>>>>>>>>>>>> something.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In your comment you have suggested that :
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * Produced/Consumed/Suppressed should extends
> >>>> Named
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * Named should have a private-package method
> >> to
> >>>> get
> >>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> specified
> >>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>> name internally (processorName())
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * Finally we should end up with something
> >> like
> >>> :
> >>>>>> Named
> >>>>>>>>>>>> ->
> >>>>>>>>>>>>>> XXX
> >>>>>>>>>>>>>>>>>>>>>>> ->
> >>>>>>>>>>>>>>>>>>>>>>>>>>> XXXInternal or Named -> Produced ->
> >>>>> ProducedInternal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The objective behind that is to :
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * consolidate the internal method
> >>> processorName()
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * consolidate the method withName that exists
> >>> now
> >>>>>>>>>>>> existing
> >>>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>>>>>>>>>>> Produced,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Consumed and Suppressed.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> But, Named is an interface so we can't
> >> define a
> >>>>>>>>>>>>>> private-package
> >>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>>> it. Also, for example Produced and
> >>>> ProducedInternal
> >>>>>> are
> >>>>>>>>>>>> not
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>>>>>>>>>> package so having a private-package method
> >>>> doesn't
> >>>>>>>>>>> really
> >>>>>>>>>>>>>> help.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In addition, if we add the withName method
> >> into
> >>>>> Named
> >>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>>>>> become confusing for developers because
> >> action
> >>>>>>>>>>> interfaces
> >>>>>>>>>>>>>>>>>>>>>>>> (ValueMapper,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Reducer, etc) extend it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The interface would look like :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> public interface Named<T extends Named<T>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> default String name() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return null;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>> default Named<T> withName(final String
> >>> name)
> >>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return null;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> So maybe instead of adding another method to
> >>>> Named
> >>>>> we
> >>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>> create a
> >>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>> package-private class that could be extended
> >> by
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Produced/Consumed/Joined/Suppressed. For
> >>> exemple,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> class SettableName<T extends SettableName<T>>
> >>>>>>>>>>> implements
> >>>>>>>>>>>>>> Named
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> protected String processorName;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> SettableName(final SettableName
> >> settable) {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> this(Objects.requireNonNull(settable,
> >>>>>> "settable
> >>>>>>>>>>>>> can't
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>> null").name());
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> SettableName(final String processorName)
> >> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> this.processorName = processorName;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
> >>>>>>>>>>>>>>>>>>>>>>>>>>> public String name() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return processorName;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>> public T withName(final String
> >>>> processorName) {
> >>>>>>>>>>>>>>>>>>>>>>>>>>> this.processorName = processorName;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return (T)this;
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In that way, we will get : public class
> >>> Produced
> >>>>>>>>>>>> implements
> >>>>>>>>>>>>>>>>>>>>>>>>>>> SettableName<Produced> { ...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 11 déc. 2018 à 02:46, Guozhang Wang <
> >>>>>>>>>>>>>>>> wangg...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I had one meta comment on the PR:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> https://github.com/apache/kafka/pull/5909#discussion_r240447153
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 10, 2018 at 5:22 PM John
> >> Roesler <
> >>>>>>>>>>>>>>>>>>>>>>> j...@confluent.io>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I hope it's ok if I ask a few questions at
> >>> this
> >>>>>> late
> >>>>>>>>>>>>>> stage...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Comment 1 ======
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems like the proposal is to add a new
> >>>>> "Named"
> >>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended to be mixed in with the existing
> >> API
> >>>>>> objects
> >>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>>>> various
> >>>>>>>>>>>>>>>>>>>>>>>>>> points.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just to preface some of my comments, it
> >> looks
> >>>>> like
> >>>>>>>>>>> your
> >>>>>>>>>>>>> KIP
> >>>>>>>>>>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>>>>>>>>> created
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> quite a while ago, so the API may have
> >>> changed
> >>>>>>>>>>> somewhat
> >>>>>>>>>>>>>> since
> >>>>>>>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> started.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> As I see the API, there are a few different
> >>>> kinds
> >>>>>> of
> >>>>>>>>>>>> DSL
> >>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> arguments:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * functions: things like Initializer,
> >>>> Aggregator,
> >>>>>>>>>>>>>>>> ValueJoiner,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ForEachAction... All of these are
> >> essentially
> >>>>>>>>>>>>>>>> Streams-flavored
> >>>>>>>>>>>>>>>>>>>>>>>>> Function
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> interfaces with different arities, type
> >>> bounds,
> >>>>> and
> >>>>>>>>>>>>>>>> semantics.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * config objects: things like Produced,
> >>>> Consumed,
> >>>>>>>>>>>> Joined,
> >>>>>>>>>>>>>>>>>>>>>>>> Grouped...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> These
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> are containers for configurations, where
> >> the
> >>>>> target
> >>>>>>>>>>> of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> configuration
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the operation itself
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * raw configurations: things like a raw
> >>>>> topic-name
> >>>>>>>>>>>> string
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Materialized:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> These are configurations for operations
> >> that
> >>>> have
> >>>>>> no
> >>>>>>>>>>>>> config
> >>>>>>>>>>>>>>>>>>>>>>> object,
> >>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> various reasons, we didn't make one. The
> >>>>>>>>>>> distinguishing
> >>>>>>>>>>>>>>>>>>>>>>> feature is
> >>>>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> target of the configuration is not the
> >>>> operation
> >>>>>>>>>>>> itself,
> >>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>>> aspect
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it. For example, in Materialized, we are
> >> not
> >>>>>> setting
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> caching
> >>>>>>>>>>>>>>>>>>>>>>>>>> behavior
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of, for example, an aggregation; we're
> >>> setting
> >>>>> the
> >>>>>>>>>>>>> caching
> >>>>>>>>>>>>>>>>>>>>>>> behavior
> >>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> materialized state store attached to the
> >>>>>> aggregation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems like choosing to mix the Named
> >>>> interface
> >>>>>> in
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>> functions
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a couple of unfortunate side-effects:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Aggregator is not the only function
> >> passed
> >>> to
> >>>>> any
> >>>>>>>>>>> of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> relevant
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> aggregate methods, so it seems a little
> >>>> arbitrary
> >>>>>> to
> >>>>>>>>>>>> pick
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>> function
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> over Initializer or Merger.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * As you noted, branch() takes an array of
> >>>>>> Predicate,
> >>>>>>>>>>>> so
> >>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>> ignore
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> provided name(s), even though Predicate
> >> names
> >>>> are
> >>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>>>>>>> elsewhere.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Not all things that we want to name have
> >>>>> function
> >>>>>>>>>>>>>>>> arguments,
> >>>>>>>>>>>>>>>>>>>>>>>>> notably
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> source and sink, so we'd switch paradigms
> >> and
> >>>> use
> >>>>>> the
> >>>>>>>>>>>>>> config
> >>>>>>>>>>>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Adding an extra method to the function
> >>>>> interfaces
> >>>>>>>>>>>> means
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>> those
> >>>>>>>>>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> no
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> longer SAM interfaces. You proposed to add
> >> a
> >>>>>> default
> >>>>>>>>>>>>>>>>>>>>>>>> implementation,
> >>>>>>>>>>>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> could still pass a lambda if we don't want
> >> to
> >>>> set
> >>>>>> the
> >>>>>>>>>>>>> name,
> >>>>>>>>>>>>>>>>>>>>>>> but if
> >>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> *do*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> want to set the name, we can no longer use
> >>>>> lambdas.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the obvious other choice would be
> >> to
> >>>> mix
> >>>>>>>>>>> Named
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>> with the
> >>>>>>>>>>>>>>>>>>>>>>>>>> config
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> objects instead, but this has one main
> >>> downside
> >>>>> of
> >>>>>>>>>>> its
> >>>>>>>>>>>>>> own...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * not every operator we wish to name has a
> >>>> config
> >>>>>>>>>>>>> object. I
> >>>>>>>>>>>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> everyone involved is comfortable with
> >> adding
> >>> a
> >>>>>> config
> >>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>> every
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> operator that's missing one.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Personally, I favor moving toward a more
> >>>>> consistent
> >>>>>>>>>>>> state
> >>>>>>>>>>>>>>>>>>>>>>> that's
> >>>>>>>>>>>>>>>>>>>>>>>>>> forward
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatible with any further changes we wish
> >>> to
> >>>>>> make.
> >>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>> *think* that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> giving
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> every operator two forms (one with no
> >> config
> >>>> and
> >>>>>> one
> >>>>>>>>>>>>> with a
> >>>>>>>>>>>>>>>>>>>>>>> config
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> object)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> would be such an API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Comment 2 =========
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Finally, just a minor comment: the static
> >>>> method
> >>>>> in
> >>>>>>>>>>>> Named
> >>>>>>>>>>>>>>>>>>>>>>> wouldn't
> >>>>>>>>>>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> properly as defined. Assuming that we mix
> >>> Named
> >>>>> in
> >>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>> Produced,
> >>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> example, we'd need to be able to use it
> >> like:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> kStream.to("out", Produced.with("myOut"))
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This doesn't work because with() returns a
> >>>> Named,
> >>>>>> but
> >>>>>>>>>>>> we
> >>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> Produced.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> We can pull off a builder method in the
> >>>>> interface,
> >>>>>>>>>>> but
> >>>>>>>>>>>>> not
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>> static
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> method.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> To define a builder method in the interface
> >>>> that
> >>>>>>>>>>>> returns
> >>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>> instance
> >>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> concrete subtype, you have to use the
> >>>> "curiously
> >>>>>>>>>>>>> recurring
> >>>>>>>>>>>>>>>>>>>>>>> generic"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would look like:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> public interface Named<N extends Named<N>>
> >> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> String name();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> N withName(String name);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can see where the name of the pattern
> >>> comes
> >>>>>> from
> >>>>>>>>>>> ;)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> An implementation would then look like:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> public class Produced implements
> >>>> Named<Produced>
> >>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> String name() { return name; }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Produced withName(final String name) {
> >>>>> this.name
> >>>>>> =
> >>>>>>>>>>>>> name;
> >>>>>>>>>>>>>>>>>>>>>>> return
> >>>>>>>>>>>>>>>>>>>>>>>>>> this;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note that the generic parameter gets filled
> >>> in
> >>>>>>>>>>> properly
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> implementing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> class, so that you get the right return
> >> type
> >>>> out.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It doesn't work at all with a static
> >> factory
> >>>>> method
> >>>>>>>>>>> at
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> level,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> so it would be up to Produced to define a
> >>>> static
> >>>>>>>>>>>> factory
> >>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>> wants
> >>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> present one.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ======
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Those are my two feedbacks!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I hope you find this helpful, rather than
> >>>>>>>>>>> frustrating.
> >>>>>>>>>>>>> I'm
> >>>>>>>>>>>>>>>>>>>>>>> sorry I
> >>>>>>>>>>>>>>>>>>>>>>>>>> didn't
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> get a chance to comment sooner.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP, I think it will be much
> >>>> nicer
> >>>>>> to
> >>>>>>>>>>> be
> >>>>>>>>>>>>>> able
> >>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor nodes.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -John
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 27, 2018 at 6:34 PM Guozhang
> >>> Wang <
> >>>>>>>>>>>>>>>>>>>>>>> wangg...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've made a pass over the PR. There are
> >> some
> >>>>>>>>>>> comments
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>> related
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the function names which may be affecting
> >>> the
> >>>>> KIP
> >>>>>>>>>>> wiki
> >>>>>>>>>>>>>> page,
> >>>>>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> overall
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think it looks good already.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Nov 16, 2018 at 4:21 PM Guozhang
> >>> Wang
> >>>> <
> >>>>>>>>>>>>>>>>>>>>>>> wangg...@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Florian! I will take a look at the
> >>> PR.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 12, 2018 at 2:44 PM Florian
> >>>>>> Hussonnois
> >>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Matthias,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry I was absent for a while. I have
> >>>>> started a
> >>>>>>>>>>> new
> >>>>>>>>>>>>> PR
> >>>>>>>>>>>>>>>>>>>>>>> for this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still in progress for now. I'm working
> >> on
> >>>> it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/kafka/pull/5909
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le ven. 19 oct. 2018 à 20:13, Matthias
> >> J.
> >>>> Sax
> >>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> matth...@confluent.io>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the status of this KIP?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/19/18 5:17 PM, Guozhang Wang
> >> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for being late... Found myself
> >>> keep
> >>>>>>>>>>>>> apologizing
> >>>>>>>>>>>>>>>>>>>>>>> for late
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replies
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these days. But I do want to push this
> >>>> KIP's
> >>>>>>>>>>>>> progress
> >>>>>>>>>>>>>>>>>>>>>>> forward
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> as I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> see it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> very important and helpful feature for
> >>>>>>>>>>>>> extensibility.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the exceptions, I've gone
> >> through
> >>>> them
> >>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> hopefully it
> >>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exhaustive list:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. KTable#toStream()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. KStream#merge(KStream)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. KStream#process() / transform() /
> >>>>>>>>>>>>> transformValues()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4. KGroupedTable /
> >>> KGroupedStream#count()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here's my reasoning:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * It is okay not letting users to
> >>> override
> >>>>> the
> >>>>>>>>>>>> name
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> 1/2,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> since
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> too trivial to be useful for
> >> debugging,
> >>>> plus
> >>>>>>>>>>> their
> >>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not determine any related topic /
> >> store
> >>>>> names.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For 3, I'd vote for adding
> >> overloaded
> >>>>>>>>>>> functions
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>> Named.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For 4, if users really want to name
> >>> the
> >>>>>>>>>>>> processor
> >>>>>>>>>>>>>> she
> >>>>>>>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>> call
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aggregate() instead, so I think it is
> >>> okay
> >>>>> to
> >>>>>>>>>>> skip
> >>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> case.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jul 6, 2018 at 3:06 PM,
> >> Florian
> >>>>>>>>>>>> Hussonnois <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The option #3 seems to be a good
> >>>>> alternative
> >>>>>>>>>>> and
> >>>>>>>>>>>> I
> >>>>>>>>>>>>>> find
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> elegant (thanks John).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But, we still have the need to
> >> overload
> >>>>> some
> >>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>>>>>>>>> either
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they do
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not accept an action instance or
> >>> because
> >>>>> they
> >>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>> translated
> >>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, this is the case for
> >>> methods
> >>>>>>>>>>>> branch()
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>> merge().
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> We
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> introduce a new interface Named (or
> >>>> maybe a
> >>>>>>>>>>>>> different
> >>>>>>>>>>>>>>>>>>>>>>> name ?)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name(). All action interfaces could
> >>>> extend
> >>>>>> this
> >>>>>>>>>>>> one
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> implement
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> option
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This would result by having the
> >>> following
> >>>>>>>>>>>> overloads
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stream<K, V> merge(final Named name,
> >>>> final
> >>>>>>>>>>>>> KStream<K,
> >>>>>>>>>>>>>>>> V>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> stream);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KStream<K, V>[] branch(final Named
> >>> name,
> >>>>>> final
> >>>>>>>>>>>>>>>>>>>>>>> Predicate<?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> super
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> K, ?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> super
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> V>... predicates)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> N.B : The list above is not
> >> exhaustive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user's code will become :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KStream<String, Integer>
> >>> stream =
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> builder.stream("test");
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KStream<String, Integer>[]
> >>>>> branches =
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>> stream.branch(Named.with("BRANCH-STREAM-ON-VALUE"),
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> Predicate.named("STREAM-PAIR-VALUE",
> >>>>>>>>>>>>>>>>>>>>>>> (k, v)
> >>>>>>>>>>>>>>>>>>>>>>>> ->
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> v
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> %
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ==
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0),
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Predicate.named("STREAM-IMPAIR-VALUE",
> >>>>>>>>>>>>>>>>>>>>>>> (k, v)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ->
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> v
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> %
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> !=
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> branches[0].to("pair");
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> branches[1].to("impair");
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is a mix of the options 3) and
> >> 1)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le ven. 6 juil. 2018 à 22:58,
> >> Guozhang
> >>>>> Wang <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wangg...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi folks, just to summarize the
> >>> options
> >>>> we
> >>>>>>>>>>> have
> >>>>>>>>>>>> so
> >>>>>>>>>>>>>>>> far:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Add a new "as" for KTable /
> >>> KStream,
> >>>>> plus
> >>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>> fields
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operators-returns-void control
> >> objects
> >>>>> (the
> >>>>>>>>>>>>> current
> >>>>>>>>>>>>>>>>>>>>>>> wiki's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposal).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pros: no more overloads.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cons: a bit departing with the
> >> current
> >>>>>>>>>>>> high-level
> >>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>> design
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DSL,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> plus, the inconsistency between
> >>>>>>>>>>>>>> operators-returns-void
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operators-not-return-voids.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Add overloaded functions for all
> >>>>>> operators,
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> accepts
> >>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> control
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> object "Described".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pros: consistent with current APIs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cons: lots of overloaded functions
> >> to
> >>>> add.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Add another default function in
> >> the
> >>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> (thank you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> J8!)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> John
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposed.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pros: no overloaded functions, no
> >>>>>> "Described".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cons: do we lose lambda functions
> >>> really
> >>>>>>>>>>> (seems
> >>>>>>>>>>>>> not
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "named"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for each func)? Plus "Described" may
> >>> be
> >>>>> more
> >>>>>>>>>>>>>>>> extensible
> >>>>>>>>>>>>>>>>>>>>>>>> than a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `String`.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My principle of considering which
> >> one
> >>> is
> >>>>>>>>>>> better
> >>>>>>>>>>>>>>>> depends
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> primarily
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "how
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to make advanced users easily use
> >> the
> >>>>>>>>>>> additional
> >>>>>>>>>>>>>> API,
> >>>>>>>>>>>>>>>>>>>>>>> while
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keeping
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hidden from normal users who do not
> >>> care
> >>>>> at
> >>>>>>>>>>>> all".
> >>>>>>>>>>>>>> For
> >>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purpose I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) > 1) > 2).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One caveat though, is that changing
> >>> the
> >>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>>>>>> would not
> >>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary-compatible though
> >>>>> source-compatible,
> >>>>>>>>>>>> right?
> >>>>>>>>>>>>>>>> I.e.
> >>>>>>>>>>>>>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recompile their code though no
> >> changes
> >>>>>> needed.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Another note: for 3), if we really
> >>> want
> >>>> to
> >>>>>>>>>>> keep
> >>>>>>>>>>>>>>>>>>>>>>>> extensibility
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Described
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we could do sth. like:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public interface Predicate<K, V> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // existing method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> boolean test(final K key, final
> >> V
> >>>>>> value);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // new default method adds the
> >>>> ability
> >>>>>> to
> >>>>>>>>>>>> name
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> predicate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> default Described described() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return new Described(null);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where user's code becomes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stream.filter(named("key", (k, v) ->
> >>>>> true));
> >>>>>>>>>>>> //
> >>>>>>>>>>>>>> note
> >>>>>>>>>>>>>>>>>>>>>>>> `named`
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> now
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sets a Described("key") in
> >>>> "described()".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>> stream.filter(described(Described.as("key",
> >>>>>> /*
> >>>>>>>>>>>> any
> >>>>>>>>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>>>>>> fancy
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the future*/), (k, v) -> true));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I feel it is not much likely that
> >> we'd
> >>>>> need
> >>>>>> to
> >>>>>>>>>>>>>> extend
> >>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> further
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> future, so just a `String` would be
> >>> good
> >>>>>>>>>>> enough.
> >>>>>>>>>>>>> But
> >>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> listing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibilities here.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jul 6, 2018 at 8:19 AM, John
> >>>>>> Roesler <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> j...@confluent.io
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry I'm late to the party, but I
> >>>> missed
> >>>>>> the
> >>>>>>>>>>>>>> message
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> originally.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding the names, it's probably
> >> a
> >>>> good
> >>>>>>>>>>> idea
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> stick to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> character set we're currently
> >> using:
> >>>>>> letters,
> >>>>>>>>>>>>>>>>>>>>>>> numbers, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hyphens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> names are used in Kafka topics,
> >> files
> >>>> and
> >>>>>>>>>>>>> folders,
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> RocksDB
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> databases,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and we also need them to work with
> >>> the
> >>>>> file
> >>>>>>>>>>>>> systems
> >>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Windows,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Linux,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MacOS. My opinion is that with a
> >>>>> situation
> >>>>>>>>>>> like
> >>>>>>>>>>>>>> that,
> >>>>>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> better
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conservative. It might also be a
> >> good
> >>>>> idea
> >>>>>> to
> >>>>>>>>>>>>>> impose
> >>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>> upper
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> limit on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> length to avoid running afoul of
> >> any
> >>> of
> >>>>>> those
> >>>>>>>>>>>>>>>> systems.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems like there's a small
> >> debate
> >>>>>> between
> >>>>>>>>>>> 1)
> >>>>>>>>>>>>>>>>>>>>>>> adding a
> >>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KStream (and maybe KTable) to
> >> modify
> >>>> its
> >>>>>> name
> >>>>>>>>>>>>> after
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> fact,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> piggy-backing on the config objects
> >>>> where
> >>>>>>>>>>> they
> >>>>>>>>>>>>>> exist
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they don't. To me, #2 is the better
> >>>>>>>>>>> alternative
> >>>>>>>>>>>>>> even
> >>>>>>>>>>>>>>>>>>>>>>> though
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> produces
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more overloads and may be a bit
> >>> awkward
> >>>>> in
> >>>>>>>>>>>>> places.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The reason is simply that #1 is a
> >>>>>> high-level
> >>>>>>>>>>>>>>>>>>>>>>> departure from
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> graph-building paradigm we're using
> >>> in
> >>>>> the
> >>>>>>>>>>> DSL.
> >>>>>>>>>>>>>>>>>>>>>>> Consider:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Graph.node1(config).node2(config)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vs
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> Graph.node1().config().node2().config()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We could have done either, but we
> >>>> picked
> >>>>>> the
> >>>>>>>>>>>>>> former.
> >>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> probably
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a good goal to try and stick to it
> >> so
> >>>>> that
> >>>>>>>>>>>>>> developers
> >>>>>>>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> develop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rely
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on their instincts for how the DSL
> >>> will
> >>>>>>>>>>> behave.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I do want to present one
> >> alternative
> >>> to
> >>>>>>>>>>> adding
> >>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>> config
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> objects:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just add a "name()" method to all
> >> our
> >>>>>>>>>>> "action"
> >>>>>>>>>>>>>>>>>>>>>>> interfaces.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll demonstrate how we can add a
> >>>> "name"
> >>>>> to
> >>>>>>>>>>>>>> Predicate
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name a "KStream#filter" DSL
> >> operator:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public interface Predicate<K, V> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // existing method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> boolean test(final K key,
> >> final V
> >>>>>> value);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // new default method adds the
> >>>>> ability
> >>>>>> to
> >>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> predicate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> default String name() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return null;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // new static factory method
> >> adds
> >>>> the
> >>>>>>>>>>>> ability
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> wrap
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> lambda
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> predicates
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with a named predicate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> static <K, V> Predicate<K, V>
> >>>>>> named(final
> >>>>>>>>>>>>>> String
> >>>>>>>>>>>>>>>>>>>>>>> name,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> final
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Predicate<K, V> predicate) {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return new Predicate<K,
> >> V>()
> >>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public boolean
> >>> test(final K
> >>>>>> key,
> >>>>>>>>>>>>> final
> >>>>>>>>>>>>>> V
> >>>>>>>>>>>>>>>>>>>>>>>> value) {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return
> >>>>> predicate.test(key,
> >>>>>>>>>>>>> value);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public String name() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return name;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then, here's how it would look to
> >> use
> >>>> it:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Anonymous predicates continue to
> >>>> work
> >>>>>> just
> >>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stream.filter((k, v) -> true);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Devs can swap in a Predicate
> >> that
> >>>>>>>>>>> implements
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> name()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stream.filter(new Predicate<Object,
> >>>>>>>>>>> Object>() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public boolean test(final
> >> Object
> >>>> key,
> >>>>>>>>>>> final
> >>>>>>>>>>>>>>>> Object
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> value) {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return true;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Override
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public String name() {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return "hey";
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> });
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // Or they can wrap their existing
> >>>> lambda
> >>>>>>>>>>> using
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> static
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> factory
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stream.filter(named("key", (k, v)
> >> ->
> >>>>>> true));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just a thought.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Overall, I think it's really
> >> valuable
> >>>> to
> >>>>> be
> >>>>>>>>>>>> able
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processors,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for all the reasons you mentioned
> >> in
> >>>> the
> >>>>>> KIP.
> >>>>>>>>>>>> So
> >>>>>>>>>>>>>>>>>>>>>>> thank you
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> introducing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -John
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 5, 2018 at 4:53 PM
> >>> Florian
> >>>>>>>>>>>>> Hussonnois <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, thank you very much for all
> >> you
> >>>>>>>>>>>> suggestions.
> >>>>>>>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> started
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> update
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP (
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>> 307%3A+Allow+to+define+custom+processor+names+with+KStreams+DSL
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, I propose to rename the
> >>>> Processed
> >>>>>>>>>>> class
> >>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Described -
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more meaningful (but this is just
> >> a
> >>>>>> detail).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm OK to not enforcing uppercase
> >>> for
> >>>>>>>>>>> specific
> >>>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> allow
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> arbitrary names with whitespaces
> >> for
> >>>>>>>>>>> example ?
> >>>>>>>>>>>>>>>>>>>>>>> Currently,
> >>>>>>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tell
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this can lead to some side
> >> effects ?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 11 juin 2018 à 01:31,
> >>> Matthias
> >>>>> J.
> >>>>>>>>>>> Sax
> >>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> matth...@confluent.io
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just catching up on this thread.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the general idea. Couple
> >> of
> >>>>>>>>>>> comments:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I think that adding
> >> `Processed`
> >>>> (or
> >>>>>>>>>>> maybe
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>> different
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> name?)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid proposal for stateless
> >>>> operators
> >>>>>> that
> >>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>>>> have a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overload
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> atm. It would align with the
> >>> overall
> >>>>> API
> >>>>>>>>>>>>> design.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - for all methods with multiple
> >>>>> existing
> >>>>>>>>>>>>>>>>>>>>>>> overloads, we
> >>>>>>>>>>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extend `Consumed`, `Produced`,
> >>>>>>>>>>> `Materialized`
> >>>>>>>>>>>>> etc
> >>>>>>>>>>>>>>>>>>>>>>> to take
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> additional
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor name (not sure atm how
> >>>>> elegant
> >>>>>>>>>>> this
> >>>>>>>>>>>>> is;
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "play" with the API a little bit;
> >>> the
> >>>>>>>>>>>> advantage
> >>>>>>>>>>>>>>>>>>>>>>> would be,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add more overloads what seems to
> >> be
> >>>> key
> >>>>>> for
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> KIP)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - operators return void: while I
> >>>> agree
> >>>>>>>>>>> that
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> "name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> first"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> chaining
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> idea is not very intuitive, it
> >>> might
> >>>>>> still
> >>>>>>>>>>>>> work,
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly (again, we would need
> >> to
> >>>>> "play"
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> API a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> little
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bit
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> see)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - for DSL operators that are
> >>>>> translated
> >>>>>> to
> >>>>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>>>>> nodes:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make sense to use the specified
> >>>>> operator
> >>>>>>>>>>> name
> >>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>> prefix
> >>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reasonable suffixes. For
> >> example, a
> >>>>> join
> >>>>>>>>>>>>>> translates
> >>>>>>>>>>>>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>>>>>>>>>> 5
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operators
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that could be name
> >>>>>>>>>>>> "name-left-store-processor",
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "name-left-join-processor",
> >>>>>>>>>>>>>>>>>>>>>>> "name-right-store-processor",
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "name-right-join-processor", and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> "name-join-merge-processor"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> similar). Maybe just using
> >> numbers
> >>>>> might
> >>>>>>>>>>> also
> >>>>>>>>>>>>>> work.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I think, we should strip the
> >>>> number
> >>>>>>>>>>>> suffixes
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>> a user
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provides
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - enforcing upper case seems to
> >> be
> >>>>>> tricky:
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> example,
> >>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enforce upper case for store
> >> names
> >>>> and
> >>>>> we
> >>>>>>>>>>>>> cannot
> >>>>>>>>>>>>>>>>>>>>>>> easily
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> change
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would break compatibility --
> >> thus,
> >>>> for
> >>>>>>>>>>>>>> consistency
> >>>>>>>>>>>>>>>>>>>>>>>> reasons
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> want to do this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - for better understand of the
> >>>> impact
> >>>>> of
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> KIP,
> >>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> helpful if you would list all
> >>> method
> >>>>>> names
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> affected
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (ie, list all newly added
> >>> overloads)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/31/18 6:40 PM, Guozhang Wang
> >>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re 1: I think changing the
> >>>>> KStreamImpl /
> >>>>>>>>>>>>>>>>>>>>>>> KTableImpl to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> allow
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> modifying
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor name after the
> >> operator
> >>> is
> >>>>>> fine
> >>>>>>>>>>> as
> >>>>>>>>>>>>>> long
> >>>>>>>>>>>>>>>>>>>>>>> as we
> >>>>>>>>>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> check
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> again
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when modifying that. In fact, we
> >>> are
> >>>>>>>>>>> having
> >>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> optimization
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on which may modify
> >>> processor
> >>>>>> names
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> final
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyways (
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>> https://github.com/apache/kafka/pull/4983
> >>>>>>>>>>> ).
> >>>>>>>>>>>>>>>>>>>>>>>> Semantically
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easier to understand to
> >> developers
> >>>>> than
> >>>>>>>>>>>>>> "deciding
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the next operator".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re 2: Yeah I'm thinking that for
> >>>>>> operators
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>> translates
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor names, we can still
> >> use
> >>>> the
> >>>>>>>>>>>> provided
> >>>>>>>>>>>>>>>>>>>>>>> "hint" to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> names, e.g. for Joins we can
> >> name
> >>>> them
> >>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>> `join-foo-this`
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `join-foo-that` etc if user
> >> calls
> >>>>>>>>>>>> `as("foo")`.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re 3: The motivation I had about
> >>>>>> removing
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> suffix is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> huge
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> restrictions on topology
> >>>>>> compatibilities:
> >>>>>>>>>>>>>> consider
> >>>>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>>> user
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> added a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operator, or library does some
> >>>>>>>>>>> optimization
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> remove
> >>>>>>>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operators,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suffix indexing may be changed
> >>> for a
> >>>>>> large
> >>>>>>>>>>>>>> amount
> >>>>>>>>>>>>>>>>>>>>>>> of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> names:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this will in turn change the
> >>>> internal
> >>>>>>>>>>> state
> >>>>>>>>>>>>>> store
> >>>>>>>>>>>>>>>>>>>>>>> names,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> well
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal topic names as well,
> >>> making
> >>>>> the
> >>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>> application
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompatible with the ones. One
> >>>>>> rationale
> >>>>>>>>>>> I
> >>>>>>>>>>>>> had
> >>>>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aligned this effort, moving
> >>> forward
> >>>> we
> >>>>>> can
> >>>>>>>>>>>>> allow
> >>>>>>>>>>>>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> customize
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal names so that they can
> >>>> still
> >>>>> be
> >>>>>>>>>>>>> reused
> >>>>>>>>>>>>>>>>>>>>>>> even
> >>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> changes
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (e.g. KIP-230), so I think
> >>> removing
> >>>>> the
> >>>>>>>>>>>> suffix
> >>>>>>>>>>>>>>>>>>>>>>> index
> >>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applicable in the long run.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 31, 2018 at 3:08 PM,
> >>>>> Florian
> >>>>>>>>>>>>>>>>>>>>>>> Hussonnois <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi ,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you very much for your
> >>>>> feedback.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree that overloading most
> >> of
> >>>> the
> >>>>>>>>>>>> methods
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Processed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ideal.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've started modifying the
> >>> KStream
> >>>>> API
> >>>>>>>>>>> and
> >>>>>>>>>>>> I
> >>>>>>>>>>>>>> got
> >>>>>>>>>>>>>>>>>>>>>>> to the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also ading a new method
> >> directly
> >>> to
> >>>>>>>>>>>>> KStreamImpl
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KTableImpl
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seems to be a better option.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> However a processor name cannot
> >>> be
> >>>>>>>>>>>> redefined
> >>>>>>>>>>>>>>>> after
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operator
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe I miss something in the
> >>>> code).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From my understanding, this
> >> will
> >>>> only
> >>>>>> set
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> KStream
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> property
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor name previsouly added
> >>> to
> >>>>> the
> >>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>> builder -
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leading
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> InvalidTopology exception.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So the new method should
> >> actually
> >>>>>> defines
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> name of
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Below is an example :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *stream.as <http://stream.as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>> (Processed.name("MAPPE_TO_UPPERCASE")*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * .map( (k, v) ->
> >>>>>>>>>>> KeyValue.pair(k,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> v.toUpperCase()))*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think this approach could
> >> solve
> >>>> the
> >>>>>>>>>>> cases
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returning
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void ?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding this new method we
> >> have
> >>>> two
> >>>>>>>>>>>>> possible
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementations
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Adding a method like :
> >>>>>>>>>>>> withName(String
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> processorName)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. or adding a method
> >>> accepting
> >>>> an
> >>>>>>>>>>>>> Processed
> >>>>>>>>>>>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as(Processed).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think solution 2. is
> >> preferable
> >>>> as
> >>>>>> the
> >>>>>>>>>>>>>>>> Processed
> >>>>>>>>>>>>>>>>>>>>>>>> class
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enriched
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> further (in futur).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As Guozhang said some operators
> >>> add
> >>>>>>>>>>>> internal
> >>>>>>>>>>>>>>>>>>>>>>>> processors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example the branch() method
> >>>>> create
> >>>>>>>>>>> one
> >>>>>>>>>>>>>>>>>>>>>>>> KStreamBranch
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> route
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> records and one
> >>> KStreamPassThrough
> >>>>>>>>>>>> processor
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> each
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In that situation only the
> >> parent
> >>>>>>>>>>> processor
> >>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>> named.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> children
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processors we could keep the
> >>>> current
> >>>>>>>>>>>>> behaviour
> >>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suffix
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (i.e
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KSTREAM-BRANCHCHILD-)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This also the case for the
> >> join()
> >>>>>> method
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> result to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processors to the topology
> >>>>> (windowing,
> >>>>>>>>>>>>>> left/right
> >>>>>>>>>>>>>>>>>>>>>>> joins
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merge
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think, like for the branch
> >>> method
> >>>>>> users
> >>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> define a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name prefix.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we should still added
> >> a
> >>>>> suffix
> >>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> "-0000000000"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name and enforce uppercases as
> >>> this
> >>>>>> will
> >>>>>>>>>>>> keep
> >>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistency
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ones generated by the API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4/
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, the KTable interface
> >> should
> >>> be
> >>>>>>>>>>>> modified
> >>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>>> KStream
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> allow
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> custom
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor names definition.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le jeu. 31 mai 2018 à 19:18,
> >>> Damian
> >>>>>> Guy <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> damian....@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> écrit
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP. What about
> >>>>> KTable
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>>>>> DSL
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interfaces?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not want to be able to do the
> >>> same
> >>>>>>>>>>> thing?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to see a
> >>> complete
> >>>>> set
> >>>>>>>>>>> of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> public
> >>>>>>>>>>>>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damian
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, 30 May 2018 at 19:45
> >>>>> Guozhang
> >>>>>>>>>>>> Wang <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wangg...@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP. I have
> >> some
> >>>>> meta
> >>>>>>>>>>>>>> feedbacks
> >>>>>>>>>>>>>>>>>>>>>>> on the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposal:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. You mentioned that this
> >>>>>> `Processed`
> >>>>>>>>>>>>> object
> >>>>>>>>>>>>>>>>>>>>>>> will be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> added
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overloaded variant of all the
> >>>>>> stateless
> >>>>>>>>>>>>>>>>>>>>>>> operators,
> >>>>>>>>>>>>>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stateful
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operators? Would like to hear
> >>>> your
> >>>>>>>>>>>> opinions
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thought
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> note for stateful operators
> >>> they
> >>>>> will
> >>>>>>>>>>>>> usually
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>> mapped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor node names, so we
> >>>>> probably
> >>>>>>>>>>> need
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> come up
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ways
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> define all their names.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. I share the same concern
> >>> with
> >>>>> Bill
> >>>>>>>>>>> as
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> lots
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overload
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functions into the stateless
> >>>>>> operators,
> >>>>>>>>>>>> as
> >>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> effort in trimming them since
> >>>> 1.0.0
> >>>>>>>>>>>>> release.
> >>>>>>>>>>>>>> If
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> goal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some "hints" on the generated
> >>>>>> processor
> >>>>>>>>>>>>> node
> >>>>>>>>>>>>>>>>>>>>>>> names,
> >>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enforcing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the exact names that to be
> >>>>> generated,
> >>>>>>>>>>>> then
> >>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function to `KStream` and
> >>>> `KTable`
> >>>>>>>>>>>> classes
> >>>>>>>>>>>>>>>> like:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "as(Processed)",
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> semantics as "the latest
> >>>> operators
> >>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> generate this
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KStream
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KTable
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be named accordingly to this
> >>>> hint".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The only caveat, is that for
> >>> all
> >>>>>>>>>>>> operators
> >>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `KStream#to`
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `KStream#print` that returns
> >>>> void,
> >>>>>> this
> >>>>>>>>>>>>>>>>>>>>>>> alternative
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the current operators:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a. KStream#print,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> b. KStream#foreach,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c. KStream#to,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> d. KStream#process
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I personally felt that except
> >>>>>>>>>>>>>> `KStream#process`
> >>>>>>>>>>>>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> usually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother to override their
> >> names,
> >>>> and
> >>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> `KStream#process`
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> overload variant with the
> >>>>> additional
> >>>>>>>>>>>>>> Processed
> >>>>>>>>>>>>>>>>>>>>>>>> object.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. In your example, the
> >>> processor
> >>>>>> names
> >>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>>>>>>> added
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suffix
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -0000000000", is this
> >>>> intentional?
> >>>>> If
> >>>>>>>>>>>> yes,
> >>>>>>>>>>>>>> why
> >>>>>>>>>>>>>>>>>>>>>>> (I
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> thought
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specified processor name
> >> hints
> >>> we
> >>>>>> will
> >>>>>>>>>>>> not
> >>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>>>>> suffix
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> distinguish
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different nodes of the same
> >>> type
> >>>>> any
> >>>>>>>>>>>> more)?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 29, 2018 at 6:47
> >>> AM,
> >>>>> Bill
> >>>>>>>>>>>>> Bejeck
> >>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bbej...@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Florian,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP. I think
> >>>> being
> >>>>>>>>>>> able
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> context
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processor names would be
> >>> useful.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea of adding a
> >>>>>>>>>>>>>>>>>>>>>>> "withProcessorName" to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Produced,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consumed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Joined.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But instead of adding the
> >>>>>> "Processed"
> >>>>>>>>>>>>>>>>>>>>>>> parameter to a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> large
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> percentage
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the methods, which would
> >>> result
> >>>> in
> >>>>>>>>>>>>>> overloaded
> >>>>>>>>>>>>>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (which
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> removed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> quite a bit with KIP-182)
> >> what
> >>>> do
> >>>>>> you
> >>>>>>>>>>>>> think
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to the AbstractStream class
> >>>>>>>>>>>>> "withName(String
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processorName)"?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I"m
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> married to the method name,
> >>> it's
> >>>>> the
> >>>>>>>>>>>> best
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>> can do
> >>>>>>>>>>>>>>>>>>>>>>>> off
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> top
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> head.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the methods that return
> >>>> void,
> >>>>>> we'd
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameter,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would at least cut down on
> >> the
> >>>>>> number
> >>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> overloaded
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just my 2 cents.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, May 27, 2018 at 4:13
> >>> PM,
> >>>>>>>>>>> Florian
> >>>>>>>>>>>>>>>>>>>>>>> Hussonnois
> >>>>>>>>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fhussonn...@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to start a new
> >>>>>>>>>>> discussion
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>> 307%3A+Allow+to+define+custom+processor+names+with+KStreams+DSL
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is still a draft.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Looking forward for your
> >>>>> feedback.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> -- Guozhang
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Florian HUSSONNOIS
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Florian HUSSONNOIS
> >>>>
> >>>
> >>
> >
> >
>
>
