Re: GObject Serialization

[Jody Goldberg <jody gnome org>]

On Fri, Oct 29, 2004 at 09:13:07AM +0500, Zeeshan Ali wrote:
> 
> > 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. :)

In Gnumeric I've got on the order of 20 formats.  Everything thing
from binary goo in structured files to raw ascii.  I don't like the
notion of trying to put an if tree of 20 items in several places.

> > 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?
Sounds reasonable.

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

My point with the xml-dom trees is that the string/buffer approach
may not apply to all serialization targets.

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

You want this interface as part of GObject itself ??
My thought was that the interfaces would be GInterfaces.  Objects
could implement them as desired.   All we'd end up with would be
your
g_object_serialise_as_sometype (GObject *obj, SomeTypeContext *)