From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtLP3-00067c-O8 for qemu-devel@nongnu.org; Mon, 02 Nov 2015 15:08:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtLOz-0006Sn-Qq for qemu-devel@nongnu.org; Mon, 02 Nov 2015 15:08:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtLOz-0006Sj-Ij for qemu-devel@nongnu.org; Mon, 02 Nov 2015 15:08:25 -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 E10578EA45 for ; Mon, 2 Nov 2015 20:08:24 +0000 (UTC) References: <5633C8EC.8030309@redhat.com> <874mh44wvs.fsf@blackfin.pond.sub.org> <56378572.5020203@redhat.com> <87egg8nro5.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <5637C2B3.6090609@redhat.com> Date: Mon, 2 Nov 2015 13:08:19 -0700 MIME-Version: 1.0 In-Reply-To: <87egg8nro5.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gh9W56c8gTaILder2mHJpKqxJRxIxqxng" Subject: Re: [Qemu-devel] RFC: libyajl for JSON List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Luiz Capitulino , "qemu-devel@nongnu.org" , "Dr. David Alan Gilbert" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gh9W56c8gTaILder2mHJpKqxJRxIxqxng Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/02/2015 12:10 PM, Markus Armbruster wrote: >>> * Single-quoted strings >=20 >> So that is an absolute must for whatever parser we choose. My first >> glance at libyajl is that it does NOT currently allow single quotes (n= ot >> even with any of its existing options), so we'd have to pre-process >> input before feeding it to yajl. >> >> I'll ask on the yajl mailing lists, to get a feel for community >> receptiveness, before attempting to actually write patches on that fro= nt. >=20 > Makes sense. On IRC, I got pointed to a couple of forks that have already done this, such as: https://github.com/ludocode/yajl/commits/master although the upstream author Lloyd was not on the channel at the time. Meanwhile, there's 47 open issues on the upstream repo: https://github.com/lloyd/yajl/issues which implies slow response by the author, but at least he WAS asking if anyone would like to help him with maintenance: https://github.com/lloyd/yajl/issues/161 | lloyd commented on Sep 24 | ok, give me a minute to hand you a patch on a branch to review. | lloyd commented on Sep 24 | ok, I'll merge down and roll a new release within a day. [still hasn't happened yet...] | lamont-granquist commented on Sep 25 | hey @lloyd would you consider adding other maintainers? | lloyd commented on Oct 1 | I would absolutely consider additional maintainers. Who's interested? so I don't know what the future holds for extending things upstream. To date, I don't have a github account, by conscious personal choice; so I can't really take him up on that offer directly. So far, I've been trying the mailing list to see if he answers that in addition to the github PR stream, but the archives show it to be pretty full of spam: http://librelist.com/browser/yajl/ >> >> Yes; the yajl parser has 4 modes of parse operation based on which of >> three callbacks you implement: double-only (yajl_double), long long-on= ly >> (yajl_integer), double-and-int (both yajl_double and yajl_integer, not= >> sure which one has precedence if input satisfies both formats), or >> custom number (yajl_number, which is given a string, and you turn it >> into the format of your choice). Likewise, the yajl formatter has 2 >> functions: yajl_gen_double() (formats doubles) and yajl_gen_number() >> (you provide literal strings formatted how you like). >=20 > Good. And one of the open bugs on the tracker was the same one we've encountered ourselves: yajl is locale-sensitive when using strtod() for parsing and when using printf() for printing doubles: https://github.com/lloyd/yajl/issues/79 [I would love for C/POSIX to add strtod_l and printf_l, but that's a thread for another day] >=20 >>> More extensions or pitfalls might be lurking in our parser. Therefor= e, >>> replacing our parser by a suitable library is not without risk. I gu= ess >>> we could do it over a full development cycle. No way for 2.5. >>> >> >> Absolutely not for 2.5; we've missed softfreeze, and this would count = as >> a new feature. Another interesting bug report against yajl: one reporter made the point [1] that yajl is already a superset of the canonical RFC 4627 definition of JSON [2], because while the RFC states that a JSON document has this terminal state: JSON-text =3D object / array yajl will accept _any_ JSON value (not just objects/arrays) as the overall document. [1] https://github.com/lloyd/yajl/issues/154 [2] https://www.ietf.org/rfc/rfc4627.txt 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). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --gh9W56c8gTaILder2mHJpKqxJRxIxqxng Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWN8KzAAoJEKeha0olJ0Nq39MIAKaPHN/NAHq1Q8CjcgbFAxMh 21QXbDNmPzVWMgBsj07K+nobjmWFg1OpRZzLKFHXcjJQGKOGSaGT25d402zhHnVg h5jPHpPk56LWzPsjTSJcwqLdoe6azROezOqTg/d067FwCrKc1CKhvQg950c9fdgw 0wcTyXLsOpOOST5XFGTcXnr+zBqjLWYLQSw+KiRUzQ0dXdJroJPk8bUI9jGbAomP dGvseCB9OxHGn78bBnjBW9kz1CmDeZpcwZnSTenVI1Uw0sYaN2ShzXbEBOAzUtIa jsv8XC+xKZS3PB/cor0ZRxZh8s0QdN+JU0ZYUg7EdfoXSFMAvb00b+AYOUEbAfg= =KBnb -----END PGP SIGNATURE----- --gh9W56c8gTaILder2mHJpKqxJRxIxqxng--