GNOME Bugzilla – Bug 643511
D-Bus: Support ObjectPath called parameter in GDBus servers
Last modified: 2018-05-22 13:56:29 UTC
Created attachment 182111 [details] [review] D-Bus: Support ObjectPath called parameter in GDBus servers When adding a method to a DBus Object (server) that includes one parameter of type GLib.ObjectPath with the DBus attribute "called_object_path = true", then it's used for referencing the called object path. This allows to create just one DBus object (or just one kind), and register it for multiple paths, then you can perform multiple actions for each called path in methods. While this is not so needed with register_object, this is a must for implementing the register_subtree GDBus feature. The patch includes also a check for dbus client: if a called object path is used, then it's not considered when connecting to the dbus method itself. =================================================================== Here's an example working with it: [DBus (name = "org.example.BasicDemo")] public class DemoServer : Object { private int counter; public int ping (string msg, GLib.BusName sender, [DBus (called_object_path = true)] GLib.ObjectPath path) { stdout.printf ("%s - %s - %s\n", msg, sender, path); switch (Path.get_basename(path)) { case "demo": print("Using the demo path obj\n"); break; case "subpath": print("Using the subpath subpath obj\n"); break; } return counter++; } public int ping_obj_path (string msg, GLib.BusName sender, GLib.ObjectPath path) { stdout.printf ("%s - %s - %s\n", msg, sender, path); return counter++; } } void on_bus_aquired (DBusConnection conn) { try { var server = new DemoServer (); conn.register_object ("/org/basic/example/demo", server); conn.register_object ("/org/basic/example/demo/subpath", server); } catch (IOError e) { stderr.printf ("Could not register service\n"); } } void main () { Bus.own_name (BusType.SESSION, "org.Basic.Example.Demo", BusNameOwnerFlags.NONE, on_bus_aquired, () => {}, () => stderr.printf ("Could not aquire name\n")); new MainLoop ().run (); }
I fail to see how you could use that with register_subtree as that doesn't use Vala's D-Bus marshalling. Am I missing something here? I'm also wondering whether it might make more sense to just support GDBusMessage parameters instead to avoid having to add support for even more special parameters.
Well, register_subtree isn't supported yet, but I'm working on it, that's why this is a first thing that needs to be done (I meant that this is a pre-requisite for implementing it in Vala). However, about reducing the usage of special parameter: you're right. I've just used a new une since the natural way for getting an ObjectPath was using it as parameter; by the way this was wrong since an ObjectPath could be used also as a DBus parameter. So, maybe using DBusMessage could be fine, also if: wouldn't it give too much power to the called method? DBusMessage allows to perform many low-level operations, not just to get data. This is not bad for me, but I don't know if you'd prefer to keep everything simpler and less controllable. Another solution (but maybe is too redoundant) could be making another subclass of ObjectPath like DBus.CalledObjectPath but I don't like that.
Created attachment 182175 [details] [review] D-Bus: Support DBusMessage called parameter in GDBus servers This new patch simply allows to retrieve the called DBusMessage just adding a method parameter of that type. However, since just the message headers are needed we could: 1) Subclass Variant in a new abstract class DBusMessageHeader and then create all the subclasses like DBusMessageHeaderPath, DBusMessageHeaderInterface (and so on, for all the kinds of headers that we would like to allow to export to a method). 2) Simply check if one of the parameter is of type GLib.DBusMessageHeaderField.* and, export the requested value.
Sorry, forgot the second option, those aren't types :P
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/173.