+1 for Binding Dropping the Kamelet part makes it clearer that you can bind more than just Kamelets.
Keeping it as "Binding" gives Kubernetes users a pretty good idea of what it's going to do without reading the documentation. On Mon, Aug 16, 2021 at 2:04 PM Antonin Stefanutti <anto...@stefanutti.fr.invalid> wrote: > Hi Luca, all, > > +1 for Binding. > > Users in the Kubernetes ecosystem may already be familiar with the term, > as it seems it's the choice made by projects like Knative and Service > Binding, > to convey the general concept of "integrating" in their respective domain. > > I find projecting that concept into the integration domain to be a good > fit, which > Would materialises in Kubernetes as bindings.camel.apache.org< > http://bindings.camel.apache.org> resources. > > On 16 Aug 2021, at 10:27, Luca Burgazzoli <lburgazz...@gmail.com<mailto: > lburgazz...@gmail.com>> wrote: > > Hello, > > When the KameletBinding concept was introduced in camel-k, if was meant to > bind two Kamelets and nothing more, but over time we have added more > capabilities, like: > > - support for processing steps to transform exchanges/messages > - support to address/source from different systems so the source/sink does > not need be a kamelet anymore > > So I think the term KameletBinding is not more appropriate and to reduce > confusion, we should try to find a better name. > > On top of my mind, I'd see the following names as a possible replacement: > - Binding so leave Kamelet out of the game as Kamelets are one of the > option but not the exclusive on > - Connector as in essence, a KameletBinding describe how to connect A to B > > Any opinion ? > > --- > Luca Burgazzoli > >
