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
> > >
> >
>
--
-- Guozhang
