Re: GVariant for prez!
- From: Havoc Pennington <havoc pennington gmail com>
- To: David Zeuthen <david fubar dk>
- Cc: desrt desrt ca, gtk-devel-list gnome org
- Subject: Re: GVariant for prez!
- Date: Sat, 2 May 2009 13:35:58 -0400
Hi,
On Sat, May 2, 2009 at 1:02 PM, David Zeuthen <david 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]