After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643511 - D-Bus: Support ObjectPath called parameter in GDBus servers
D-Bus: Support ObjectPath called parameter in GDBus servers
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: D-Bus
unspecified
Other All
: Normal normal
: ---
Assigned To: Michael 'Mickey' Lauer
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-02-28 17:48 UTC by Marco Trevisan (Treviño)
Modified: 2018-05-22 13:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
D-Bus: Support ObjectPath called parameter in GDBus servers (4.11 KB, patch)
2011-02-28 17:48 UTC, Marco Trevisan (Treviño)
none Details | Review
D-Bus: Support DBusMessage called parameter in GDBus servers (3.22 KB, patch)
2011-03-01 12:17 UTC, Marco Trevisan (Treviño)
none Details | Review

Description Marco Trevisan (Treviño) 2011-02-28 17:48:43 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 ();
}
Comment 1 Jürg Billeter 2011-03-01 09:36:09 UTC
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.
Comment 2 Marco Trevisan (Treviño) 2011-03-01 11:29:34 UTC
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.
Comment 3 Marco Trevisan (Treviño) 2011-03-01 12:17:33 UTC
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.
Comment 4 Marco Trevisan (Treviño) 2011-03-01 12:21:37 UTC
Sorry, forgot the second option, those aren't types :P
Comment 5 GNOME Infrastructure Team 2018-05-22 13:56:29 UTC
-- 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.