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