Re: GObject Serialization

[Jody Goldberg <jody gnome org>]

On Fri, Oct 29, 2004 at 12:33:55AM +0500, Zeeshan Ali wrote:
> 
>   So what i conclude is that, the object should itself have
> serialization capabilities. Now I thought out two ways to achieve
> this:
> 
> 1. To add serialization/deserialization methods into GObject class
> itself, which would implement the non-introspective way. All the other
> objects can then over-ride those methods to implement a better
> Serialization. The problem with this way is that you are forcing
> Serialization on everyone without providing a good default
> implementation for it.
> 
> 2. To do it the Java way: have an interface named 'GSerializable' or
> 'GSerializableObject' in the gobject core, which can be implemented by
> anyone who wants his object to support Serialization.

I've used a combination of both in libgoffice.  We serialise
selected properties (an extra flag in class_init), but also provide
an interface so that objects can serialise extra information.
 
There are still some gotchas when handling versioning.  You may want
some hooks to facilitate object/property renaming.

> gchar * g_serializable_save_thyself (GSerializable *serializable, gchar *mime);
> 
>    This method would be responsible to serialize a given instance into
> the format requested by the calling function through the mime
> argument. The method should serialize the object on an allocated
> buffer and return it. In case of failure, e.g if the object doesn't
> support serialization into the mime type requested it should return a
> NULL.

Interesting, but I'm not sure that a double dispatch mechanism like
that is necessary.  Having a pile of code of the form
    if (!strcmp (mime, "xml")) {
    } else if (!strcmp (mime, "CSV")) {
    }...
seems ugly, and unlikely to scale when faced with real world
formats.  You're going to need a way to pass in context information
about the import/export state.  As an example, MS Office objects
reference colours and fonts from outside the object specs.

It's also somewhat questionable to assume that all formats make
sense as strings.  Are those nul terminated ?  What encoding ?
Someone may have wanted to serialise into a dom tree for internal
use, strings would be ugly there.

>   This of course is just a rough idea. Criticism and Corrections both
> are welcome. :)

I'd suggest a set of interfaces, one for each format.  That will
give enough power to handle the idiosyncrasies of all the different
formats.