You're right that what OBI does is structural typing or just interfaces, not duck typing. Transforms and bindings do use the adapter pattern. The critique lands and I can admit it. The duck typing framing was rhetorically appealing but imprecise.
On the gRPC-as-client-layer point, I want to make sure I understand. You're suggesting that between the OBI client SDK and the source service, there should be a gRPC layer, with generated gRPC adapters fronting each source? Or something else?
Worth noting either way: the spec doesn't dictate implementation. It defines operation contracts, binding sources, and the executor role. How an executor actually reaches a service is left open, so gRPC-based routing is a valid strategy within the spec regardless.
Thanks for sticking with this. This is exactly the kind of discussion I was hoping for. I really do appreciate it.
On the gRPC-as-client-layer point, I want to make sure I understand. You're suggesting that between the OBI client SDK and the source service, there should be a gRPC layer, with generated gRPC adapters fronting each source? Or something else?
Worth noting either way: the spec doesn't dictate implementation. It defines operation contracts, binding sources, and the executor role. How an executor actually reaches a service is left open, so gRPC-based routing is a valid strategy within the spec regardless.
Thanks for sticking with this. This is exactly the kind of discussion I was hoping for. I really do appreciate it.