[riwsky]

My gRPC point is that it already gives you a language for describing interfaces and support for generating client types from it, and already abstracts the connection management[1]. If OBI just generated a gRPC ClientConn implementation to map the Invoke calls to eg REST paths, it’d inherit the large existing gRPC client ecosystem. That ClientConn interface can already technically capture what OBI calls binding executors. People don’t do this though because it’s not worth it.

[1]: https://github.com/grpc/grpc-go/blob/06fc26a196350499dd0cf2d...

[clevengermatt]

Thanks for the clarification. That's a valid implementation strategy for client consumers that want a gRPC feel. The spec doesn't require any particular client pattern (what's on the site is guidance, not normative), so an OBI-conformant toolchain could be built that way. I went with a less prescriptive approach, but that's a preference, not a mandate, and I think it's the right choice specifically for leaving the door open to alternative client implementation patterns like what you're proposing. I appreciate you sticking with this across the thread.

If you're open to it, I'd be interested in staying in touch as OBI evolves. I know you're not sold on the project, but critical voices willing to engage constructively for this long are rare and valuable regardless. If you ever want to poke at something or tell me where you think it's going wrong, I'm at https://x.com/clevengermatt, and there's the GitHub discussions.