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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list