Re: GVariant for prez!

["Freddie Unpenstein" <fredderic excite com>]

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.
	Click Here For More Information