I think rolling our own defeats the purpose of replacing what we have. We should pick something where there is a large sets of client libraries already. As you say, performance is not critical, so pick one that is popular. I think gRPC would be fine too.
— Leif > On Aug 16, 2018, at 11:59, Derek Dagit <der...@oath.com.INVALID> wrote: > > I was not at Cork, so I am probably missing a lot of the details. > > It seems having true RPC here would greatly expand the possibilities for > management and monitoring. > > > - What are the current and planned use cases for this RPC? > > - What if we want to add authentication/authorization for multi-tenant > management and isolation? > > - What about security issues and the ongoing cost of maintaining a unique > RPC solution, versus using something already battle-tested? > > - Didn't we try this once already? [0] > > > (I figure there are good answers to all of these questions, and so I am > mostly asking for the benefit of those of us not familiar with the past > discussions.) > > [0] https://github.com/apache/trafficserver/pull/3504#issuecomment-389927441 > > > > What are the current and planned use cases for this RPC? > > On Thu, Aug 16, 2018 at 2:39 PM, Alan M. Carroll < > a...@network-geographics.com> wrote: > >> I've been looking at how to do the RPC replacement that was agreed on at >> Cork. After looking at grpc, Avro, and Thrift, I don't like any of them for >> our use case. I've moved to the camp that says we should build our own thin >> wrapper around YAML messages, very similar to a REST style API. We do not >> need high performance for this case, the message rate is generally less >> than one per second and the messages are not large. Previously going YAML >> would have been a major effort but since we've already paid that price in >> the ongoing configuration conversion, building an RPC on top of YAMLCPP >> seems quite easy. In this scheme the data is sent via YAML map instances. >> In each map, the top level keys are the messages, each key being a tag that >> identifies the message handler. The handler is given the map entry, key and >> value, and processes it. If parallelism is needed, the handlers can attach >> an "sequence" field inside the map value to match requests to responses. >> >> The RPC driver is simple. It has a hash of tags to handlers/continuations. >> It accumulates data from the socket until it gets a successful YAML parse. >> Then it walks the top level keys, dispatching an event for each one to the >> handler associated with the tag. Sending is done handing a YAML map object >> to the RPC, which puts it in a queue to be written by a blocking write >> thread. My view is this would be less work than integrating a full featured >> RPC with many features we don't need. >> >> > > > -- > Derek
