Well, and this is a bit nit-picky, but the JSON-RPC spec does require
that a compliant implementation return a parse error if given invalid
JSON. We could relax that if we wish, but it feels like it invites
bugs.
Also, it looks like yaml-cpp does emit yaml that is not json:
https://github.com/jbed
I spent some time discussing this with Jason. We agree the key question
here is, given YAMLCPP as a serializer, are there any cases where it will
produce non-JSON output? Any incoming requests that are pure JSON will be
parsed without a problem by YAMLCPP. But is the reverse true, that any
output f
That's one of the things that attracted me to this idea. Once you've got a
JSON/YAML parser, everything else is easy. You frequently don't even need
the serializer - for your examples, those are just as easily done with
`printf` as an official serializer.
I'm also unclear if there is a really a di
t;>
> >>>>>>>> Yeah, it's not like we have any expertise in asynchronous I/O on IPC
> >>>>>>>> sockets, that would let us leverage someone else's YAML based
> >>>>>>> serialization
> >>&g
l be *easy*! And I can't
>>>>>> wait
>>>>>>>> to play with all the super cool features and adjustable knobs such a
>>>>>>> thing
>>>>>>>> will have.
>>>>>>>>
>>>>>>>>>
t;>>>>
>>>>> - 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]
>>
nswers 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-38992744
>>
> >>>>>>> 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
> >>>>>>>
ere 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
>>>>>
t;>>>
> >>>>>> On Aug 16, 2018, at 11:59, Derek Dagit
> >>> wrote:
> >>>>>>
> >>>>>> I was not at Cork, so I am probably missing a lot of the details.
> >>>>>>
> >>>>>>
gt;> 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
> >>> - 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
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
>
> >>> (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/p
uestions, 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
>>>
>>>
>>>
>>&
m/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&
> On Aug 16, 2018, at 3:17 PM, Leif Hedstrom wrote:
>
> 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 thin
> 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 gr
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 m
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
file
te:
> 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
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 s
22 matches
Mail list logo
