Re: GVariant for prez!

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

2009/4/9 Dan Winship <danw gnome org>:
> Ryan Lortie wrote:
>> The type system, of course, is that of DBus.
>>
>> I love your feedback.  Please give it all to me.
>
> I took at a look at GVariant from the perspective of "could I make
> libsoup's XML-RPC (and future JSON) code use GVariant instead of
> GValue". (For more background, see the thread starting at
> http://www.mail-archive.com/gtk-devel-list gnome org/msg09241.html).
>
> But the answer to the question is no, because GVariant doesn't have a
> (strongly-typed) date/time type like XML-RPC does. (Yes, I could do
> something like decide that inside libsoup, the int64 type means time_t,
> but that's lame, and would interfere with using the XML-RPC int64
> extension type that some services support, and it doesn't solve the
> general problem.)
>
> So, my feedback is, if the type system is explicitly just D-Bus and
> nothing else, shouldn't it be called "GDBusType" or something? (I'm not
> saying it's *bad* that it's D-Bus-specific, just that it should be more
> explicit about it.)
>
> (Alternate possibility: add a way to include type tags, so that callers
> and callees can agree that a particular "x" is to be treated as a time_t
> and not a generic int64. Eg, a signature of ":x" would mean a (string)
> type tag followed by an int64, but it would be distinct from "sx" or
> "(sx)".)
>

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.

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.

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

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

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

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

-- 
Cheers,
Mikkel