Michael Gasch

IMHO these scenarios can happen on K8s svc: 1) One port 2) Two or more ports (1) is an easy one. (2) could be decided based on port naming (required...

I actually wanted to propose the same ideas (don’t depend on order, use annotation) shared by @odacremolbap :) But I also agree that changing the duck might not be feasible...

A concrete example is this [source](https://github.com/vmware-tanzu/sources-for-knative/). Across several of the Tanzu related Knative projects (brokers, sources, etc.) we‘re trying to standardize on `kncloudevents` to keep client logic similar. In this...

> I think I'd lean most towards 2 or 3. Injecting the client via context seems like a pattern we use all over the rest of the place, why not...

> the rate limiter at the CE producer client confused me (I still think that is not a valid scenario) but customizing HTTP options for custom retrying when sending sounds...

> The receiver case is clear (and people like me who have been developing sinks using the adapter would benefit from it, I'm all in for this), I am still...

After a great chat with @odacremolbap here's a proposal how to allow for custom CE client `[]http.Option` in the adapter injection phase without breaking the API: 1) Add a new...

> and thinking that there are way too many constructors Agree. > And then building the client with all provided options I'm a big fan of the options pattern, so...

Btw: something to also bring up in our discussion whether it's safe to assume that this CE client will be replaced by `pkg/kncloudevents` anytime soon, rendering some of these discussions...

> Using a new CloudEvents client constructor we could keep backwards compatibility but inject by context any option. Nice. > We could open a different discussion to make clear which...