CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @markdroth
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

Regardless of discussion at #42912, @markdroth I think this is something we could easily get agreement. Although I need some time to re-consider the implementation. We still need to keep backward compatibility to the previous version. We need some hack to validate the new style and old style will not be used at same time. 🤔 But we can land the API first.

BTW, although Envoy need to keep backward compatibility, but gRPC may could have a fresh start if the feature haven't been released in the gRPC?

/lgtm api

Regardless of discussion at #42912, @markdroth I think this is something we could easily get agreement.

Absolutely! This looks great!

Although I need some time to re-consider the implementation. We still need to keep backward compatibility to the previous version. We need some hack to validate the new style and old style will not be used at same time. 🤔

What I was thinking is this:

• If using Composite message inside ExtensionWithMatcher (the old API), the new matcher field will be ignored (or we could even decide to reject the config if the field is set).
• If using Composite message as the top-level filter config (the new API), the matcher field will be required.

Either API would result in the same filter being configured.

BTW, although Envoy need to keep backward compatibility, but gRPC may could have a fresh start if the feature haven't been released in the gRPC?

Sadly, it's probably too late for that. I've already started implementing the composite filter in gRPC C++, since we need it fairly quickly for an important feature, and we're going to need to deploy it in an environment where the control plane supports both gRPC and Envoy. I don't think there's enough time to get the new API implemented in Envoy and get all of our Envoy instances upgraded before we need to deploy this. :(

On the plus side, once we agree on this new API, it will be trivial for gRPC to add support for it.

What I was thinking is this:
If using Composite message inside ExtensionWithMatcher (the old API), the new matcher field will be ignored (or we could even decide to reject the config if the field is set).
If using Composite message as the top-level filter config (the new API), the matcher field will be required.

Yeah, exactly. This is what I am thinking. Although in the Envoy, there is no way for filter implementation to know whether it's configured in the ExtensionWithMatcher or top level filter chain. Still need some hack.

Anyway, I will try to resolve this problem and add implementation at next 2-3 weeks.

cc @agrawroh for an approval for this API only change. Then I can prepare the implementation. This is independent topic about how to improve composite self. (For now, TBH, it's over-complicated even as an expert-tool. Orz).

because Mark have approved this API before, let's merge it directly.