On 05/02/2016 03:15 AM, Markus Armbruster wrote: > Title: s/json/JSON/ > > Eric Blake <ebl...@redhat.com> writes: > >> We have several places that want to go from qapi to JSON; right now, >> they have to create an intermediate QObject to do the work. That >> also has the drawback that the JSON formatting of a QDict will >> rearrange keys (according to a deterministic, but unpredictable, >> hash), when humans have an easier time if dicts are produced in >> the same order as the qapi type. > > There's a drawback, though: more code. > > Could the JSON output visitor replace the QMP output visitor?
Yes, it turned out quite nicely to write qobject_to_json() on top of a
JSON output visitor. And in fact, doing so makes it trivial to write a
QObject deep-cloner - pass the QObject to the qmp-output-visitor instead
of the json-output-visitor!
>> +static void json_output_type_any(Visitor *v, const char *name, QObject
>> **obj,
>> + Error **errp)
>> +{
>> + JsonOutputVisitor *jov = to_jov(v);
>> + QString *str = qobject_to_json(*obj);
>> + assert(str);
>
> Can't happen.
Can too. From tests/check-qobject-json.c:
obj = QOBJECT(qstring_from_str(utf8_in));
str = qobject_to_json(obj);
if (json_out) {
g_assert(str);
g_assert_cmpstr(qstring_get_str(str), ==, json_out);
} else {
g_assert(!str);
}
where the failures occur when it is impossible to output proper UTF-8
due to invalid encoding in a string. Arguably, that case would be nicer
if it could set an Error* (and would make my argument for setting an
error on Inf/NaN for numbers also a bit more tenable), but that is
additional work that I haven't tackled yet. I'm trying to get the series
posted for another round of review, where I've done some major
reshuffling (such as doing the clone visitor first, not second, in the
series), so hopefully later today.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
