From: "Mikkel Kamstrup Erlandsen", Date: 13/04/2009 21:45, Wrote:
> How about dropping GVariant data in a human readable form to a
> file? I often find myself in the following scenario: I have data that
> is really not well suited for GConf and can't fit in a GKeyFile, and I
> also want to allow enterprising script kiddies to tweak the output
> data via shell scripts and such. The last thing requires that people
> can grok the data just by looking at the file. I am not keen on
> writing yet-another-gmarkup-parser for my app. Outputting GVariants as
> JSON or what have we, would probably be ideal.
This would probably be possible if serialisation were performed in two stages.
An object would have a serialisation function that emits an array (or list) of
GType objects representing its individual data elements. A function could then
walk the array (or list), rendering those elements in whatever way it sees fit.
GType could help by providing methods to render its value in binary (including
a type identifier and data length if necessary) and textual forms. This would
even allow for serialisation engines to be constructed, for example, to handle
space/speed tradeoffs during the process. Of course, that means extra work
keeping the serialisation function in sync with the data structure, but does
allow computed fields to be omitted, etc.
A JSON serialiser would take the GType series and represent the values as text.
Likewise a binary serialiser would take the binary representation of each
GType element. All that would be needed, is for GType to provide the value and
size of its serialised content, and indicate whether it's a simple or compound
object (ie. whether it contains any non-trivial GTypes that may been to be
serialised independently). The last point allows a serialisation engine to
avoid having to explicitly store each and every sub-objects type and size, by
storing the object itself first, and allowing the objects serialisation handler
to provide the type information. GVarient then, basically need only be a
mechanism of serialising the objects type information prior to the object
itself.
Mind you, creating an entire GType for each field to be serialised might come
with its own rather nasty cost. I wonder if there's an easier way to achieve
the same goal... (Maybe the GType class pointer, and a pointer to the actual
element within the object, giving two constant pointers per data element,
making the array approach very attractive, especially with the help of a little
code generation?)
> It has been discussed elsewhere in this thread that GVariant is a
> parallel type system to GType. While I think this is true to some
> extend I also think it is good. Intermixing the type system from an OO
> platform with that of a serialization framework is Just A Bad Idea
> (TM). They are simply solving two different problems, it seems related
> to the RPC-vs-message passing problem.
The object system deals with the allocation and construction of an object, and
subsequent destruction and deallocation of its resources when it closes.
Serialisation and deserialisation are alternative methods to the same process
(especially on the construction side, serialisation doesn't always involve
destruction). Personally, I don't see how they can be kept separate, without
sacrificing extensibility.
Just some ideas based on how I've tackled the serialisation problem myself, in
the past...
Fredderic
------------------------------------------------------------
Term Life Insurance
Get a life insurance quote online. Click to compare rates and save.
http://tagline.excite.com/fc/FgElN1g6op8iJivre7pB43ZYVedHbEkoQG2U5GngUXw4GbuVP93p24WZBJ2/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
