envoyproxy/envoy

Separate out Envoy platform API from extension API

Open

#5126 aperta il 26 nov 2018

Vedi su GitHub
 (4 commenti) (0 reazioni) (0 assegnatari)C++ (5373 fork)batch import
design proposalhelp wanted

Metriche repository

Star
 (27.997 star)
Metriche merge PR
 (Merge medio 8g) (378 PR mergiate in 30 g)

Descrizione

We currently have a bit of conflation in api/ between those APIs that are provided a platform abstraction layer (mostly for the benefit of core Envoy, but also extensions) and the APIs that will one day act as a stable interface for extensions. For example:

https://github.com/envoyproxy/envoy/blob/2c0733ad3ffaf3e1630e3a77e822c5d76ad08f0b/include/envoy/api/api.h#L28

is clearly in the second category, and

https://github.com/envoyproxy/envoy/blob/2c0733ad3ffaf3e1630e3a77e822c5d76ad08f0b/include/envoy/api/api.h#L54

is in the first. This becomes even stranger when we have the ApiImpl require access to a stats object in

https://github.com/envoyproxy/envoy/blob/2c0733ad3ffaf3e1630e3a77e822c5d76ad08f0b/source/common/api/api_impl.h#L22

This is because the filesystem code is both a platform abstraction API and also providing higher level functionality like stats tracking.

Ideally, we split out the API into a api/platform and api/export, where we clearly delineate these two concerns. New platform ports of Envoy populate the interfaces in api/platform, extensions take dependencies on api/export.

CC @jmarantz @eziskind @mattklein123

Guida contributor