Re: GObject Serialization

[Stefan Kost <kost imn htwk-leipzig de>]

Hi hi,

any news about this. I now in a similar situation. I make data persitent in an
XML file and this code is very thighly bound to that structure of the data.
Mean when the data model changes, one need to make adjustments to the
saver/loader as well.
Thus I thought about serialisation as well. I don't want GObject to do the
serialisation for me as this would mean GObject chooses the format.
Therefore "all I need" is better introspection capabillities.

1.) Need to mark a property as volatile or not. Only non-volatile properties are
saved.

2.) I am not so concerned about read-only properties. I found no example of a
read-only property that would need to be serialized

3.) A major problem is that things like GList arte *not* GObjects. As you have
pointed out, if a property returns a gpointer to a e.,g. GList, the framework
can't find out about that.

In the end I am thinking about a GSerializable interface as well. That could at
first be used to find out if an object should be serialized at all and if so
which properties need to be serialized. Aditionally it could supply some
metadata about collection-types (GList, GSList, GHashmap,...) that are
accessible via gpointer properties.

Have you already done some coding. If so I would like to look at it.

@glib developers: wouldn't it be sensible to have such an interface in glib?

Stefan

Zeeshan Ali wrote:
> Hello everyone,
>    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. :)
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 

-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -

begin:vcard
fn:Stefan Kost
n:Kost;Stefan
org:HTWK Leipzig;FB. IMN
adr:;;Postfach 301166;Leipzig;;04251;Germany
email;internet:kost imn htwk-leipzig de
title:Dipl. Informatiker
tel;work:+49341 30766440
tel;home:+49341 2253538
tel;cell:+49178 3183742
x-mozilla-html:FALSE
url:http://www.imn.htwk-leipzig.de/~kost/about.html
version:2.1
end:vcard