All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: libyajl for JSON
Date: Tue, 03 Nov 2015 16:08:58 +0100	[thread overview]
Message-ID: <87d1vr86id.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <20151103092659.126ab97c@redhat.com> (Luiz Capitulino's message of "Tue, 3 Nov 2015 09:26:59 -0500")

Luiz Capitulino <lcapitulino@redhat.com> writes:

> On Tue, 3 Nov 2015 14:53:59 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> On 03/11/2015 14:46, Luiz Capitulino wrote:
>> >> > 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.
>> 
>> I'm not sure what's so bad about our parser that makes it worthwhile to:
>
> It's not that it's bad. It's about the advantages of dropping hundreds of
> lines of NIH code and switching to something more widely used.

I wish we would've / could've avoided NIH back then, but I'm not sure
getting rid of this piece of NIH now is worthwhile.

json-{lexer,parser,streamer}.[ch] together have 949 SLOC.  I'm not
counting tests, because we'd most likely keep them anyway.  This is less
than 0.1% of the QEMU source code :)

Maintenance hasn't been costing us a fortune exactly: 40 commits in six
years.

I'm annoyed by its relative shoddiness, but the prospect of having to
fix it up isn't something that keeps me up at night.

>                                                                Also,
> any maintenance time we spend on libyajl will also be automatically
> enjoyed by libvirt which is excellent.

Excellent indeed *if* upstream is responsive.

> On the other hand, I don't want to push too hard for it because I do
> recognize that switching has a cost and I won't be able to help with
> that myself.
>
>> 1) uglify all tests and make them inconsistent with the QAPI schemas,
>> which also uses single-quoted strings
>
> This doesn't seem hard to fix, we could pre-process the test files,
> say in Python, to add the needed escaping.

The test files are actually C code... sure you want to mangle C code in
Python?

>> 2) waste time finding a replacement for % interpolation (the best
>> replacement here would be to rewrite the tests in Python IMHO, but
>> that's not a small ask)
>
> Is this only used by tests?

No.

>                             Can you give an example of this feature?

Yes:

    static QDict *build_qmp_error_dict(Error *err)
    {
        QObject *obj;

        obj = qobject_from_jsonf("{ 'error': { 'class': %s, 'desc': %s } }",
                                 ErrorClass_lookup[error_get_class(err)],
                                 error_get_pretty(err));

        return qobject_to_qdict(obj);
    }

Builds a QDict with a single key "error".  Its value is a QDict with key
"class", value ErrorClass_lookup[error_get_class(err)], and key "desc",
value error_get_pretty(err), where "value" really means the C string
quoted for JSON and wrapped in a QString.

As I wrote elsewhere in the thread, we could build this by hand.  Much
less readable, but that might be tolerable, as the feature isn't widely
used.  I'm not thrilled about it, though.  It's too easy to forget the
quoting.

To find more examples, try "git-grep _json[fv]".

>> Just let's remove the weird (to not say worse) usage of QDict/QList to
>> store tokens...

Any replacement effort will have to compete on merits with fixing up
what we have.

  parent reply	other threads:[~2015-11-03 15:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 19:45 [Qemu-devel] RFC: libyajl for JSON Eric Blake
2015-10-30 20:16 ` Peter Maydell
2015-11-02  8:40 ` Markus Armbruster
2015-11-02 11:49   ` Paolo Bonzini
2015-11-02 12:56     ` Markus Armbruster
2015-11-02 13:47       ` Paolo Bonzini
2015-11-02 14:10   ` Stefan Hajnoczi
2015-11-02 15:46   ` Eric Blake
2015-11-02 19:10     ` Markus Armbruster
2015-11-02 20:08       ` Eric Blake
2015-11-03  7:17         ` Markus Armbruster
2015-11-03 13:19           ` Luiz Capitulino
2015-11-03 13:38             ` Paolo Bonzini
2015-11-03 13:46               ` Luiz Capitulino
2015-11-03 13:53                 ` Paolo Bonzini
2015-11-03 14:26                   ` Luiz Capitulino
2015-11-03 14:53                     ` Paolo Bonzini
2015-11-03 15:08                     ` Markus Armbruster [this message]
2015-11-03 13:40             ` Eric Blake
2015-11-03 13:44               ` Daniel P. Berrange
2015-11-03 13:53               ` Luiz Capitulino
2015-11-02 13:17 ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1vr86id.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.