Re: GVariant for prez!
- From: Ryan Lortie <desrt desrt ca>
- To: Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>
- Cc: Dan Winship <danw gnome org>, gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: GVariant for prez!
- Date: Mon, 13 Apr 2009 15:05:10 -0400
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
* 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
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
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 :)
] [Thread Prev