-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
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:
Line 28 in 2c0733a
| virtual Event::DispatcherPtr allocateDispatcher(Event::TimeSystem& time_system) PURE; |
is clearly in the second category, and
Line 54 in 2c0733a
| virtual Thread::ThreadPtr createThread(std::function<void()> thread_routine) PURE; |
is in the first. This becomes even stranger when we have the ApiImpl require access to a stats object in
envoy/source/common/api/api_impl.h
Line 22 in 2c0733a
| Stats::Store& stats_store); |
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.