I was told that it would be a good idea to put my proposal here so it does'nt
get ignored/forgoten. So I am simply pasting what i sent to the ML here:

   In this email, I intend to propose a model for GObject
Serialization. Before the actual proposal itself, I would describe the
whole story which lead me to this conclusion. The impatient should
simply move to the Conclusion below.

BACKGROUND:
  Some months back I was writing an application for an embedded (not
in the true sense though) system and I needed object persistence in
that. I quickly realized that for implementing object persistence, I
need to implement object serialization first. So I started to write
code to do that. Here is the summary of what I did:

1. Wrote a DTD, which was nothing but a small hack on glade-2.0.dtd
2. Wrote two functions:
    gchar * g_object_to_xml (GObject *object);
    GObject * g_object_from_xml (gchar *xml);

    These functions were dependent on the what object used to show to
you through readable props. This code worked quite well for my simple
objects but as I wrote the two functions, I realized that there are a
lot of problems with this non-introspective method,  e.g

1. Not all important props are readable.
2. Even if the a prop. is readable it may be of a type which the
serialization code may not know howto handle, e.g gpointers.

 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.

 The 2nd option seems to be the best to me, so lets suppose we chose
to go this way. Now the question is how should the GSerializable
interface look like. Let's say it contains the following methods:

gchar * g_serializable_to_xml (GSerializable *serializable);
GSerializable * g_serializable_from_xml (GSerializableClass
*serializable_class, gchar *xml);

 The above methods look very nice and innocent at the first sight.
But as you look closely, it is XML specific. Despite the fact that XML
is QUITE a generic format but it's still not generic enough.

 Many people may be simply jumping to the conclusion below and I had
to address all, so dont be surprised for being treated as a perfect
stranger. :)

Conclusion:
 My conclusion, rather a proposal to the gobject developer's team is
to add an interface into the gobject core library, named
'GSerializable' (or anything they like) which would have the following
two methods (at least):

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.

GSerializable * g_serializable_restore_thyself (GSerializableClass
*serializable_class, gchar *buffer, gchar *mime);

  This method would be responsible to construct an instance from the
data given through the buffer argument. The data which must be in the
format specified through the mime argument. The method should
serialize the object on an allocated buffer and return it. In case of
failure, like if the object doesn't support deserialization from the
mime type requested it should return a NULL.

GSList * g_serializable_supported_formats (GSerializableClass *serializable);

 This method would simply be responsible to return a list of
supported mime types.

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