Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino <lcapitulino@redhat.com>]

[I thought I had replied to this thread, but it doesn't seem so. So,
 I'll try again]

On Fri, 30 Oct 2015 13:45:48 -0600
Eric Blake <eblake@redhat.com> wrote:

> Loaded question in response to
> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06988.html, but
> posting as a new thread to call attention to it:
> 
> Libvirt uses libyajl to parse and format JSON. Would it be worth
> dragging in yet another prerequisite library into qemu and reuse
> libyajl's parser instead of our own hand-rolled one?

I'd be in favor of that.

I don't exactly remember why we didn't use an external library like
libyajl. Maybe it was unknown to us, or maybe having an external dep
was too painful at the time. But I do remember we looked at having
something we could merge in QEMU source code, and everything we found
had license issues.

> 
> I know that a while ago, the answer was "as long as we support
> out-of-the-box builds on RHEL 5, that platform lacks yajl therefore we
> can't depend on it" (and libvirt's solution on RHEL 5 is "qemu doesn't
> support QMP and thus doesn't use JSON and thus libvirt doesn't need yajl
> there").
> 
> But now that we have just recently bumped the minimum glib and python
> versions to something not available on RHEL 5, it may also be time to
> start thinking about outsourcing to libyajl, because as far as I can
> tell, every platform that currently supports qemu out of the box has a
> version of libyajl. And since libvirt has already figured out the grunt
> work of how to simultaneously code to both the 1.x and 2.x APIs, it's
> not that much of a stretch to reuse that work in qemu.
> 
> On the other hand, one of the "features" of qemu's hand-rolled json
> parser is the ability to do qobject_from_jsonf("{'foo':%s}", "bar")
> (that is, we extended JSON with our notion of single-quoted strings, and
> with our notion of %s and similar escape sequences for piecing together
> multiple inputs into a single input stream without having to first
> g_strdup_printf our pieces into a single string).  I don't know if
> libyajl lets us add extensions to the language it parses.
>