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
>>
>
>
signature.asc
Description: OpenPGP digital signature
