Thanks for clarifying the scope. Good notes. I do like the idea of having a schema. Hopefully if we enable external registration we could provide a way for those also to have schemas with validation.
What makes this more plausible now is the integration of YAML support to ATS, whereas before we may as well have pulled in an integrated 3rd-party library. Generally it seems like it's worth exploring. On Thu, Aug 16, 2018 at 3:19 PM, Alan Carroll < solidwallofc...@oath.com.invalid> wrote: > This is for replacing the existing internal RPC that is used to communicate > between traffic_ctl, traffic_manager, and traffic_server. This current runs > on a UNIX domain socket and that would not change. Because it's UNIX > domain, it has the same security requirements as any of the configuration > files. > > In terms of third party support, 90% or more of the work in an RPC is > serialization / deserialization. In this proposal we would leverage YAMLCPP > to do that work. The other bits of the RPC are simple and easy to > implement. We could even, if we want, make a schema for the RPC messages > and validate against it. > > We did try this with Alan Wang, it was because of his work that it was > agreed at Cork to finally deal with this issue. > > Here are my notes on this from Cork - > https://solidwallofcode.github.io/notes/ATS-Cork-WG- > Summary.en.html#process-management > -- Derek