Skip to content

Separate out Envoy platform API from extension API #5126

@htuch

Description

@htuch

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:

virtual Event::DispatcherPtr allocateDispatcher(Event::TimeSystem& time_system) PURE;

is clearly in the second category, and

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

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.

CC @jmarantz @eziskind @mattklein123

Metadata

Metadata

Assignees

No one assigned

    Labels

    design proposalNeeds design doc/proposal before implementationhelp wantedNeeds help!

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions