That's what we have now and it's not worked out well. The problem is there is a central dispatcher and it needs to be able to parse the messages at least to the extent of knowing the size of the messages. Otherwise the essential problem remains that the dispatcher can't be generic and any update in set of messages or content requires modifying that code. This in turn makes it effectively impossible for plugins to participate in any meaningful way.
On Tue, Sep 4, 2018 at 9:41 AM Walt Karas <wka...@oath.com.invalid> wrote: > For inter-process comm on a single server, why not KISS and use > message queues and POD structs? > > On Mon, Aug 27, 2018 at 2:43 PM, Alan Carroll > <solidwallofc...@oath.com.invalid> wrote: > > Because most people probably dropped off the previous discussion on this > > list, I want to call out that, as far as I can tell, the consensus for > > upgrading the internal RPC mechanism is to use a JSON based message > > exchange compliant with JSON-RPC 2.0 (https://www.jsonrpc.org/). We can > use > > YAMLCPP to parse messages and I think we can easily (externally) tweak > > YAMLCPP to output JSON. This will be very interoperable with external > tools > > along with an easy way to pass relatively complex data between > > traffic_manager / traffic_server and external tools like traffic_ctl in > > both directions. > -- *Beware the fisherman who's casting out his line in to a dried up riverbed.* *Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.* *It's easier that way. *- Genesis : Duke : VI 25-28
