Hi, On Sat, May 2, 2009 at 1:02 PM, David Zeuthen <da...@fubar.dk> wrote: > o It seems like you (or Simon or both) expect GVariant to be the only > container type in town for C bindings for D-Bus (as per the D-Bus > library bug report). E.g. you expect the C programmers to deal with > a{ss} as a GVariant instead of the more natural type GHashTable.
One thing to consider is whether we can separate the basic building block pieces from the object system mapping and get the basic building block stuff (main loop integration, name watching, etc.) into glib on an earlier schedule... then give plenty of time to bake and iterate dconf, gvariant, gdbus object mapping. Just feels like there's a lot more controvery and open questions and just plain "stuff to figure out" once we're on the object mapping level. A lot of work left, and there would be much benefit to getting some real-world usage of the work, too, before locking it down. > o I don't really like the name, I don't think it adequately > describes what GVariant is: a serialization format with an API > to access and build the value. So, I'd call it GDBusValue instead > since that really is what it is. GBinaryBlob? GBinaryValue? GDataBlob? GStructuredData? GSerializedValues? GSerialization? Repeating what I mentioned earlier, it isn't strictly speaking a dbus value at the moment... it's both a conceptual superset, and the actual format is v2/slightly-incompatible. Long-term it seems like the gvariant intent is to support both dbus, and the mmap'd file case. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list