Rename SinkBinding?

[nachocano]

Problem
In 0.12 we introduced SinkBindings, and together with ApiServerSource and PingSource form the core eventing sources.
IMO we should try to maintain consistency in how we name sources (especially the core ones), so that is crystal clear, even by just looking at its Kind, that is a source.
XSource kind of naming seems to have worked well, and we are using it mostly everywhere. We've been doing something similar for Channels (XChannel).
Other disadvantage I see about SinkBinding is that its name is explicitly talking about Sinks, not Sources.
IMO the word Binding is more of an implementation detail that shouldn't matter to the folks using this. I think the Subject of such Binding is the piece that should drive the naming. For example:

PodSpecableSource

Persona:
Which persona is this feature for?
Developer

Exit Criteria
Decide on the name for SinkBinding

Time Estimate (optional):
Infinite

Additional context (optional)
/nitpicking
/cc @n3wscott @vaikas @matzew @lionelvillard etc

[n3wscott]

Personally I hate Source in the resource name but folks want it...

[n3wscott]

The thinking with this name is that other bindings around the env are binding this to that. In the case of LogBinding (OSBAPI), it binds a log collector to a subject. SinkBinding binds a resolved sink+sugar for cloudevents into a subject.

It does not bind a source to a subject, the subject is the source implementation. The binding provides the rest of the control plane contract to that implementation to allow it to not need to resolve the sink.

So in this case, I think SinkBinding is the correct direction for this object.

A more verbose name would be something like CloudEventsConsumerBinding and CloudEventsConsumer==Sink in Knative Eventing

[mattmoor]

Source in the resource name is kinda silly if you primarily deal with yaml because it's always right there in the apiVersion:

apiVersion: sources.knative.dev/v1alpha1
kind: Foo

In Go style, this is often referred to as stutter with the package name.

It's also notable that SinkBinding has a wholly different arity than a typical source because it's a meta source. I can use a selector to turn every Deployment in the namespace into a Source, which kinda makes the Deployment the logical source, not the SinkBinding, even though the latter implements the Source duck.

[rhuss]

+1 for being consistent with other sources naming. If SinkBinding IS-A source, then it should follow the (implicit) naming convention for sources, i.e. having a Source suffix in the name.

What is the key-characteristics that all sources have in common ? If we look at the intersection of all sources out there, it's that a source pumps something into sink. The same what a SinkBinding enables (in combination with the subject). However, that something is different from source-to-source (and in case of the SinkBinding its delegated to the subject)

SinkBinding is a binding to/from (let's ignore the direction for a moment) a sink (which actually is the 'source characteristics', i.e. putting something into a sink), so the names Sink and Source a more or less the same in this context imo.

I understand the real source is the combination of the referenced subject + binding part, but what is managed by the Knative user is the binding only (assuming that the referenced subject is managed outside of Knative), which moves the focus on this binding as being the actual managed source.

So long story short: What's about using BindingSource ?

• It would follow the established naming convention (suffice Source)
• It indicates that it binds to something
• However it makes it clear that it IS-A Source (and hence can be managed like any other source, eg. with kn source ....)

An alternative could be DelegatingSource (or to some degree AdapterSource or ProxySource, but that does not really nail it)

PodSpecableSource would be techically also correct, but maybe its, hmm, too technical ?

[rhuss]

Source in the resource name is kinda silly if you primarily deal with yaml because it's always right there in the apiVersion:

True, but reasoning about objects seldomly involves the API group (expect when dealing with yaml): Documents, clients arguments, kubectl get output,, .. doesn't include the group.

It's also notable that SinkBinding has a wholly different arity than a typical source because it's a meta source

A meta source is a source, too, isn't it ? Technically I totally agree with you, that a SinkBinding is only one half of the equation, but one can equally take the POV, that it's just a super set for a DeploymentSource, JobSource, StatefulSetSource, the same way like a KafkaSource connects a Kafka cluster (the 'real' source) with a sink. IMO a SinkBinding is not much that special.

It was before my time, but I could imagine that the discussion Importer vs. Source went similar :) (aka. Source as name being not technical correct, but still preferred over Importer for some reason)

[nachocano]

the subject is the source implementation

Yes, that's why I think the naming should be driven by the subject... which is the actual source

[matzew]

I like BindingSource - or PodspecableSource

On Tue 4. Feb 2020 at 19:20, Ignacio (Nacho) Cano ***@***.***> wrote: the subject is the source implementation Yes, that's why I think the naming should be driven by the subject... which is the actual source — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2499?email_source=notifications&email_token=AABGPTTJMFRT4WMREJBAW5LRBGWXRA5CNFSM4KP2445KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKYVE3Q#issuecomment-582046318>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGPTULOD7L4CQ53NSYWQTRBGWXRANCNFSM4KP2445A> .

-- Sent from Gmail Mobile

[rhuss]

the subject is the source implementation

Is the referenced subject as much the source implementation like it is the Kafka cluster for a KafkaSource (with the KafkaSource controller providing the 'binding') ?

In the context of Knative (which added it own interpretation of what a "source" is), I think the naming should be driven by the sink aspect (as this is the common part of all sources).

[mattmoor]

If we look at the intersection of all sources out there, it's that a source pumps something into sink

Except the SinkBinding doesn't pump anything into the sink, it binds that information into the podspecable so that it can.

If SinkBinding IS-A source, then it should follow the (implicit) naming convention for sources, i.e. having a Source suffix in the name

I would say that the SinkBinding IS-A Binding too, perhaps moreso than it is a Source because it's a sort of meta-Source or Source factory. By the logic that these things should both appear in the name, SourceBinding feels most consistent to me.

[mattmoor]

To further clarify my preference for ordering here: What comes first feels like the qualifier on what comes second. It is a Binding, what is it Binding? The Source information into the PodSpecable. Ergo SourceBinding or PodSpecableSourceBinding, though the latter is quite a mouthful. 🤣

{Subject}{Content}Binding feels like the right anatomy of Binding names to me, even if it results in huge names 😬

[rhuss]

Looks like we have some hard time to decide whats being the main noun in a combined word describing two nearly equivalent aspects. As a German I have huge experience in squeezing many words in a single word, so you have to trust me ;-P

Jokes aside, let me bring in another perspective from the client side: The decision we have to make is whether we should offer the binding management on the same level as any other source, or should we use a different syntax for managing bindings (e..g kn source binding .... vs kn binding ...). For eventing source handling will there be any binding other than for binding podspecables ? If we settle on using the same management level for the sink binding as for source (kn source binding create), I really would appreciate a name that follows the other source naming schemes (Source at the end). BTW, currently we already have kn source binding although we are managing "SinkBinding" objects. No problem for us, but confusing for the user.

@n3wscott on slack you mentioned some possible alternate bindings like a TwitterBinding etc., but I have no idea what benefit that would have over a (typed) TwitterSource ? Would the subject part of such a TwitterBinding be any useful outside the context of Knative eventing and used without a binding ? (if its always used together with a binding then it should be combined to a 'classic' source)

[rhuss]

To further clarify my preference for ordering here: What comes first feels like the qualifier on what comes second. It is a Binding, what is it Binding? The Source information into the PodSpecable. Ergo SourceBinding or PodSpecableSourceBinding, though the latter is quite a mouthful.

But the PodSpecable is not a Source, too, as it lacks the sink reference (brought in by the binding). An then why not CloudEvent instead of Source as this might better pinpoint the "content" ? E.g. PodSpecableCloudEventBinding (did I mention that I'm German speaking ? :)

I think we should not strive for absolut technical correctness but for describing the usage best to provide a coherent UX.

My preference so would be still "BindingSource" as a sink binding is been used and managed like a source (in the context of eventing sources). And if it looks like a 🦆, it is a 🦆, isn't it ? :). The alternative could be "MetaSource" but that's probably too vague.

[nachocano]

I think we should not strive for absolut technical correctness but for describing the usage best to provide a coherent UX.

+100

[nachocano]

BindingSource

I'm fine with this. I think is better than SinkBinding