-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Closed
Labels
design proposalNeeds design doc/proposal before implementationNeeds design doc/proposal before implementationstalestalebot believes this issue/PR has not been touched recentlystalebot believes this issue/PR has not been touched recently
Description
As discussed in various previous issues, e.g. #3155, and my post at https://blog.envoyproxy.io/dynamic-extensibility-and-protocol-buffers-dcd0bf0b8801, we want to head towards using Any as the canonical extension type. This is more efficient on the wire and we're now seeing use cases (e.g. Istio CC @costinm) where Any would be bring a real pay-off.
We will continue to support Struct embedded inside an Any for those folks who prefer working with such types.
Rather than adhoc switching to Any, we should aim to maintain a consistent API theme around opaque extension configuration.
My recommendation is this:
- We come up with a clean way to switch to Any and turndown the use of Struct for extensions. This might be just adding in an Any replacement with a oneof with the existing Struct uses.
- We do this across all APIs in one sweep. We tag the Struct opaque data as deprecated. All future extension APIs only use
Any. - We support Structs embedded in Any fields in the implementation, to provide flexibility to folks who want to continue using Struct.
With the right use of templated conversion utils, I think this can be done without a lot of boiler plate.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
design proposalNeeds design doc/proposal before implementationNeeds design doc/proposal before implementationstalestalebot believes this issue/PR has not been touched recentlystalebot believes this issue/PR has not been touched recently