Re: GVariant for prez!
- From: David Zeuthen <david fubar dk>
- To: desrt desrt ca
- Cc: gtk-devel-list gnome org
- Subject: Re: GVariant for prez!
- Date: Sat, 02 May 2009 13:02:39 -0400
Hey Ryan,
I took a closer look at GVariant today so here are some more comments,
take them, leave them or do whatever you want with them ;-)
Most of these comments are general but, for other readers, it might help
to also read the conversations in
http://bugzilla.gnome.org/show_bug.cgi?id=579571
(GVariant discussion starts around comment 70)
to see where I'm coming from.
o In general, I think GVariant is a very useful data type since
you can serialize instances to disk and send them over the
network or to different processes or whatever.
Especially for something like replacing GConf, this is extremely
useful - no doubt we want to avoid IPC overhead where possible (e.g.
read from shared memory or files or whatever) and use IPC where it
makes sense (for transactions involving writes). It's nice here to be
able to use the same data type, no doubt about it.
o Any particular reason this is not based on the base object class?
There's a bunch of useful things in GObject such as
- Subclassing
- Data associations (e.g. g_object_set|get_data())
- GInterface support
- Weak references
and when bug 557100 is resolved it seems the cost of basing GVariant
on the base object class shouldn't matter.
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.
My view is that it's not really realistic to do this, I think it's
a convenient thing that I can get/pass well-known data-types like
GHashTable or GPtrArray from/to remote objects. This allows adding
D-Bus support to existing programs without fundamentally changing
how their data is represented and not having to deal with a vararg
based API should you choose to generate code.
It also seems particularly awkward to not map D-Bus APIs to native
APIs (in GLib, GptrArray, GArray and GHashTable are considered native
APIs for collections) - by the same token, would you expect Python
users to use GVariant? No, they'd want to use the native types so
they have things like hash table literals etc.
Specifically, there is no equivalent of g_hash_table_lookup() etc.
right now on GVariant but I suppose you can add that.
(Btw, if GVariant was based on GObject and we added collection
interfaces to the GLib stack (like some people want, cf. bug
560061), then you'd just make GVariant implement the these
interfaces and that would solve the "there is no
g_hash_table_lookup() equivalent" complaint.)
I realize that some people are not opposed to the GVariant type
of programming. E.g. build your data up basically using an iterator,
much like the way you build a DBusMessage. Obviously, I can't speak
for others, but I personally don't like that kind of API unless I'm
tooling around with simple D-Bus services. YMMV.
That said, if we were to add the GDBus stuff I'm working on, I don't
think we should antagonize users that want this. Not so much because
choice of what collection API to use is great (as a general
sentiment), more because there are legitimate reasons for why you
want this cf. the GSettings example.
(There's also the concern that GLib is so low in the stack and it's
generally not wise to force too many dogmas on people - e.g. for
D-Bus support, force people into using GPtrArray, GArray, GHashtable
_or_ force people into using GVariant. We also want to be careful
not to paint ourselves into any corners from which we can't escape.)
o I'm worried that GVariant supports a superset of the D-Bus
protocol.
o I don't see any tests cases at all (or am I looking in the wrong
place) - this worries me.
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.
A concrete plan for landing the GVariant (which, as the douche I am, is
referring to as GDBusValue in the following) could be to make it part of
the GDBus work I'm doing
o Probably we'd switch GDBus from using DBusMessage to GDBusValue for
building messages.
- maybe we'd want a dbus_message_demarshal() that didn't validate
the data (since we'd trust GDBusValue for this) or maybe it's not
worth it (most probably is, but profiling would be good here).
o The C API for invoking methods / emitting signals would also accept
G_TYPE_DBUS_VALUE. This, basically, allows you to feed raw D-Bus
messages.
o We'd have a way for the code generator to read an annotation on
whether you'd want e.g. a GHashTable or a GDBusValue for a type
signature a{ss}. Also a command-line switch.
In fact, I was already considering having a boxed type for DBusMessage
so people can do this. But it seems wiser, as you have demonstrated, to
encapsulate DBusMessage in a native GLib type since it is useful outside
the world of IPC (where libdbus-1 is not available).
Of course all this is up to the GLib maintainers (maybe they'll merge
GVariant, maybe they'll merge GDBus, maybe they'll merge nothing!) but I
don't think landing both GDBus and GVariant without some kind of
integration work (perhaps like what I proposed) is ever going to work.
It would be truly bizarre.
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]