From a64f7faa3c10f1db9ea1bf2abf963af1f80ff4ee Mon Sep 17 00:00:00 2001 From: Leo Di Donato Date: Thu, 31 Oct 2019 16:51:51 +0100 Subject: [PATCH] fix(proposals): typos and language Signed-off-by: Lorenzo Fontana Co-authored-by: Leonardo Di Donato Co-Authored-By: Lorenzo Fontana --- proposals/20191030-api.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/20191030-api.md b/proposals/20191030-api.md index fec322a3..543dfe0b 100644 --- a/proposals/20191030-api.md +++ b/proposals/20191030-api.md @@ -2,13 +2,13 @@ ## Summary -With this proposal we inted to present the intent of creating a Falco API. +This is a proposal to better structure the Falco API. -This proposal also intends to list the set of the gRPC services such API will expose. +It will contain a list of gRPC services that can be added to have a first stable version of the API for v1.0.0. ## Motivation -We want users to interface with Falco outputs, inputs, rules, and configurations via thirdy-part clients. +We want to enable users to use thirdy-party clients to interface with Falco outputs, inputs, rules, and configurations. Such ability would enable the community to create a whole set of OSS tools, built on top of Falco. @@ -35,7 +35,7 @@ Some examples, already in place, are: - Receive Falco events with a well-defined contract over wire --> **outputs** - Receive Falco drops with a well-defined contract over wire --> **drops** - Receive current Falco version and related meta information (commit hash, built type, etc.) --> **version** -- Config Falco via API (CRUD) -> **configs** +- Configure Falco via API (CRUD) -> **configs** - Inject and/or modify Falco rules via API (CRUD) --> **rules** - Send input events to Falco over wire --> **inputs** @@ -130,7 +130,7 @@ This translates in having the following set of `proto` files. #### Benefits -We think this structure makes the implementation more easy to write and to maintain because it automatically matches to abstractions - ie., one service by RPC type, a pool of contexts by RPC type - implemented in the code. +We think this structure makes the implementation easier to write and to maintain because it automatically matches the abstractions - ie., one service by RPC type, a pool of contexts by RPC type - implemented in the code. #### Limitations