glib bindings (Was Re: [patch] gobject sender and pid)
david at fubar.dk
Mon Mar 13 16:14:17 PST 2006
On Mon, 2006-03-13 at 23:52 +0000, Robert McQueen wrote:
> > but still no dice with dbus-binding-tool.
> Hmm, how no dice? It wouldn't appear to function any differently until
> runtime - that annotation should be all you need, then in your method
> signature, don't put any out arguments, and instead of a GError, the
> last argument is a DBusGMethodInvocation instead.
Yup, that was exactly what I was missing.
> > Sure, my patch was experimental but it should really be possible to get
> > the sender for sync calls too. To write a secure system bus service, you
> > really need to know who the caller is.
> Does it really matter that much? I don't see any sensible way to attach
> a context with things like the sender and path to a synchronous call
> without turning it into something which isn't just a straight C method
> call. If you do want to involve yourself in the bus more closely and get
> an object representing the context of the call, this is what exactly
> what the async annotation does - I don't regard it as an abuse.
Yea, that makes sense to me; perhaps just make every async so developers
(like me) don't get confused :-). So.. I'm just learning the dbus-glib
bindings and so far I'm pretty happy. It's almost like C no longer
sucks :-) - A few requests still
1. Adding exceptions to introspection data; I raised this way back
and I still think it would be useful. These days I _still_ have
to grep my source code instead of just doing Introspect() or what
ever. I wonder how people writing apps speaking to HAL cope; oh
wait, we can check that; they don't handle all errors and I need
to point them to 5 different source files for them to figure out
what exceptions some method can throw... Pretty please?
2. Should we install the introspection XML somewhere? As discussed
in the thread about a year back I don't think there was any
consensus.. Ideally the hal-devel or PolicyKit-devel RPM packages
or whatever would include this just like we include header files
and library stubs in such packages. I don't really think D-BUS
services are much different.
Apart from that: great work guys, I really enjoy using these bindings!
More information about the dbus