GNOME Bugzilla – Bug 701698
Allow to serialize default values
Last modified: 2016-08-25 05:04:01 UTC
Hi, I am in the process of packaging seafile (a own dropbox/owncloud-like solution) and it uses a json-glib-1.0 fork just to apply this small patch: diff --git a/json-glib/json-gobject.c b/json-glib/json-gobject.c index 5ac93c8..9403c62 100644 --- a/json-glib/json-gobject.c +++ b/json-glib/json-gobject.c @@ -413,8 +413,9 @@ json_gobject_dump (GObject *gobject) pspec); } /* skip if the value is the default for the property */ - else if (!g_param_value_defaults (pspec, &value)) - node = json_serialize_pspec (&value, pspec); + /* else if (!g_param_value_defaults (pspec, &value)) */ + else + node = json_serialize_pspec (&value, pspec); if (node) json_object_set_member (object, pspec->name, node); My understanding that applying this patch would be quite intrusive for applications using json-glib, but maybe we could find a way how to support the serialization of default values and not break the backward compatibility.
Hi, I am a seafile [1] developer, When json-glib serializes a GObject, if some attribute of this GObject have a default value, then that attribute is ignored and won't appear in the serialized output; When deserializing this object, that attribute would get its default value. In seafile code, we use json-glib to do serialization/deserialization of the RPC call between the C backend server and python webserver. We do this by serializing the GObject in C and deserialize it in Python as a plain python dict. So the rule described above causes some problem because the python side knows nothing about the ignored attribute of the GObject. Thus we modified the code of json-glib to make it never ignore any attributes of a GObject during serialization, which is the diff showed above by Sury. I sent an email to the author of json-glib (1 year ago), but unfortunately get no response, so we included the modified version of json-glib in our rpc library [libsearpc](https://github.com/haiwen/libsearpc A possible solution to this is to provide a function to disable the describe behavior. If this feature can be added in json-glib, we would happily remove the json-glib code from libsearpc. [1] https://github.com/haiwen/seafile [2] https://github.com/haiwen/libsearpc
(In reply to comment #1) > I sent an email to the author of json-glib (1 year ago), but unfortunately get > no response, so we included the modified version of json-glib in our rpc > library > [libsearpc](https://github.com/haiwen/libsearpc I'm sorry, but I never received any email from you, or from the email address you're using, otherwise I would have replied. to be absolutely fair, I think your approach is completely wrong. the serialization and deserialization API is meant to be used between JSON-GLib users, not across library barriers; in fact, trying to deserialize something serialized with JSON-GLib with anything except JSON-GLib lies entirely in undefined behaviour territory — there's a reason the serialization format is *not* specified and documented. on top of that, serializing default values for GObject properties is pretty much pointless, and not only it makes serializing/deserializing objects less efficient, it can also mask bugs with properties having a default value not being initialized when the object instance is created. if you want to ensure that a property is serialized regardless of its default value, you should override the JsonSerializable implementation for that type; JsonSerializable has precedence over the default implementation of using the GParamSpec description of the property to try and deduce its contents.
It would be useful to have a flag/extra method to do this. - our test suite failed as we tested that output==input ... anyway - documentation is pretty essential for this behaviour. * Creates a #JsonNode representing the passed #GObject * instance. Each member of the returned JSON object will * map to a property of the #GObject * Note: default property values are not serialized