Re: GVariant for prez!

[Ryan Lortie <desrt desrt ca>]

Mikkel Kamstrup Erlandsen wrote:
> I have been silently anticipating GVariant for a while now and I am
> very happy to see it coming forth now. I am bit in the same camp as
> Dan here... My primary interest is not necessarily passing GVariants
> over DBus (although I would also love to do that), but more using
> GVariants as a handy serialization mechanism.

Glad to hear this :)


> Here follows some thoughts in the internet's answer to peanut butter,
> a bullet point list:
>
>  * I really hope there is room in GVariant for NULL values in some way
> or other. Without a NULL it is hard to map stuff from an SQL DB
> directly to the serialization format without nasty hacks. This has
> bitten me several times with DBus.

This is the one place where I really broke with the type system of DBus 
because I also believe that it is extremely important to represent these 
(and some day I hope DBus will be modified to support it too).  GVariant 
supports "maybe" types: any type can have "m" prepended to it.  For 
example, "s" is a string (may not be NULL) and "ms" is a nullable string 
(any valid string, or NULL).  It's basically the '?' type constructor 
from C#.

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

GVariant comes with a pretty-printer to XML and a parser from.  A have a 
friend who is interested in developing a printer/parser for pythonic 
text strings (this sort of thing: "[(1, 2), (3, 4), (5, 6)]").

>  * Integration with GIO and GNIO? I would love to send GVariants over
> sockets and GIO streams (much like a GDataInputStream (or maybe
> integrating GVariants into the GData*putStream API)). I don't see
> support for this right now (which is ok), but is it feasible to add in
> the future?

Definitely.  Since I'm also working on GNIO, this is something that I've 
spent a bit of time thinking about.  So far, I don't want to cause the 
two projects to mutually depend on each other until one of them gets 
committed upstream first. :)

>  * I am seeing cases where people (read: people=myself at least!) are
> more or less using DBus for sending structured data to another app
> when writing a file might be more appropriate. This applies to apps
> only started ever so often that could just as well get the data when
> the user starts them up. Using DBus for this requires installation of
> autostart services and what not, but almost seems easier than the
> current alternative.

This is the idea behind dconf, and with more or less the exact reasons 
that you give.

>  * 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. This has been proven numerous
> times in the past and discussed widely in the academia so I am not
> going link-slinging on this one, I just wanted to state my opinion.

+1 from me, obviously :)

Cheers