Re: GObject Serialization

[Zeeshan Ali <zeenix gmail com>]

Hello everyone,
     Let me comment on the comments so far:

Swan,
   Thanks, I'll definatelly have a look at it and see what I can learn
from there.

Jody,

> 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.
 
       Does'nt seem very ugly to me. I am not familliar with the
internals of Gstreamer, but as a plugin-writer, I know that it checks
for the compatibility of the two pads before connecting them together
MAINLY through mime-types and a plugin-writer declares the
mime-type(s) supported on a pad as strings. I am not sure if they are
treated as strings or not the Gstreamer core. But even if it does'nt,
we can learn from Gstreamer to make this code look as baeautifull as
you want it to. :)

> 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.

    How about one extra argument as a gpointer, the role of which
would be object-specific?

> 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.

   I did'nt really meant the data to be strings but gchar * is
generally used to repressent data in the most generic way. Maybe
declaring it as a gpointer would be a better idea.

> 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.

   Yeah right so the gobject core is ultimatelly filled with thousands
of interfaces after requests from thousands of people for each format.
I strongly disagree with your opinion here.

Xav,

> Could there be a way for the method/interface to be "blocked" for
> children ? Because just inheriting its parent's way of serializing would
> very often be wrong for a GObject.

    I think overriding of interface methods should be possible. If
it's not then we MUST add support for that first.

Thanks for the comments so far.