From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtbvF-0003dR-Sl for qemu-devel@nongnu.org; Tue, 03 Nov 2015 08:46:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtbvB-0008CV-Vk for qemu-devel@nongnu.org; Tue, 03 Nov 2015 08:46:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtbvB-0008CJ-QC for qemu-devel@nongnu.org; Tue, 03 Nov 2015 08:46:45 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 97B5114CAAA for ; Tue, 3 Nov 2015 13:46:44 +0000 (UTC) Date: Tue, 3 Nov 2015 08:46:43 -0500 From: Luiz Capitulino Message-ID: <20151103084643.26d71554@redhat.com> In-Reply-To: <5638B8DE.6020709@redhat.com> References: <5633C8EC.8030309@redhat.com> <874mh44wvs.fsf@blackfin.pond.sub.org> <56378572.5020203@redhat.com> <87egg8nro5.fsf@blackfin.pond.sub.org> <5637C2B3.6090609@redhat.com> <87egg7lffd.fsf@blackfin.pond.sub.org> <20151103081917.1d348ad1@redhat.com> <5638B8DE.6020709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: libyajl for JSON List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Markus Armbruster , "Dr. David Alan Gilbert" , "qemu-devel@nongnu.org" On Tue, 3 Nov 2015 14:38:38 +0100 Paolo Bonzini wrote: > > > On 03/11/2015 14:19, Luiz Capitulino wrote: > > > 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? > > Can you explain why that would make sense? :) (Especially since there > is another extension---JSON5---that does exactly what we're doing, so it > probably wasn't that stupid an idea). Let's be pragmatic. *If* this is the only issue stopping us from dropping our own parser in favor of something more widely used and *if* libvirt doesn't make use of the feature, it's something we should strongly consider.