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/jbeder/yaml-cpp/wiki/How-To-Emit-YAML On Mon, Aug 20, 2018 at 9:28 AM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > > 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 from YAMLCPP will be parsable by a JSON parser? If so then IMHO > we're good to go. I'm fine with using JSON-RPC, presuming it fits our needs > (which seems likely to me). > > On Mon, Aug 20, 2018 at 9:20 AM Alan Carroll <solidwallofc...@oath.com> > wrote: > > > 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 difference in JSON vs. YAML in > > this regard - any valid JSON is also valid YAML and my experience with YAML > > based serializers is they output JSON because it's (1) valid YAML and (2) > > more portable. AFAICT there is no difference between JSON and YAML with > > regard to live data structures, it's purely the syntax that's valid for > > parsing. I strongly suspect we can use YAMLCPP internally and treat it as a > > JSON interface. > > > > > -- > *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
