qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] RFC: libyajl for JSON
Date: Tue, 3 Nov 2015 06:40:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/03/2015 06:19 AM, Luiz Capitulino wrote:
> On Tue, 03 Nov 2015 08:17:58 +0100
> Markus Armbruster <address@hidden> wrote:
> 
>>> So at this point, I want to see if lloyd makes any progress towards an
>>> actual yajl release and/or adding a co-maintainer, before even trying to
>>> get formal upstream support for single quoting.  We could always create
>>> a git submodule with our own choice of fork (since there are already
>>> forks that do single-quote parsing) - but the mantra of 'upstream first'
>>> has a lot of merit (I'm reluctant to fork without good reason).
>>
>> The value proposition of replacing our flawed JSON parser isn't in
>> saving big on maintenance, it's in not having to find and fix its flaws.
>>
>> If the replacement needs a lot of work to fit our needs, the value
>> proposition becomes negative.
>>
>> A JSON parser shouldn't require much maintenance, as JSON is simple,
>> doesn't change, and parsing has few system dependencies.
> 
> Let me suggest this crazy idea: have you guys considered breaking
> compatibility?

As in, requiring QMP clients to send "quotes" rather than 'quotes'?
It's worth considering (we already guarantee that our output is strict
JSON, and that the 'quotes' on input is merely for convenience).  If we
want to go that route, than 2.5 should document loudly that we are
deprecating 'quotes' in QMP, so that 2.6 can actually remove it when
switching to yajl.  And as single quotes appears to be the only JSON
extension we have been relying on, I think that would indeed free us
from having to wait for a yajl release or carry our own yajl fork.

Interesting idea; I'm still thinking whether it would help us more than
it would hurt lazy clients that were depending on the extension.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]