gdbus hides some functionality of the current dbus spec pretty well, and that is not optimal (and also introduces a lot unncessary code to be written by the library user/programmer instead of proven and tested code in glib).
Instead of ignoreing method call messages without interface field by default, the user should register a filter function to discard such messages if desired, not the other way round. After all that is still part of the current spec. As I already said, I'd be happy to adjust my patches with error-returnal-on-duplicate-member-detection ( https://bugzilla.gnome.org/show_bug.cgi?id=706675 ) if there is a chance of inclusion. Best Bernhard Schuster 2013/8/27 Simon McVittie <simon.mcvit...@collabora.co.uk> > On 22/08/13 14:54, Bernhard Schuster wrote: > > I created a demo which shows that remote method calls on interface NULL > > do not work with `g_dbus_connection_register_object`. According to > > > http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga6c8a4c5d350c1962b11300cc4dd0c2e2 > > the spec says that this is explicitly allowed for method calls. > > My opinion as a D-Bus maintainer: sending method calls "to no interface" > is allowed, but a bad idea. Its semantics are "I don't know or care > which interface I'm calling a method on, please pick one arbitrarily" > which doesn't make a whole lot of sense, since the semantics of a method > are only defined by its interface! > > The D-Bus protocol spec says: > > A method call message is required to have a MEMBER header field > indicating the name of the method. Optionally, the message has an > INTERFACE field giving the interface the method is a part of. In > the absence of an INTERFACE field, if two interfaces on the same > object have a method with the same name, it is undefined which of > the two methods will be invoked. Implementations may also choose to > return an error in this ambiguous case. > > The spec also says > > However, if a method name is unique implementations must not > require an interface field > > but that doesn't seem very well thought-out, and I'd be tempted to > delete it from the spec. For instance, messages with no interface on the > system bus will usually be shot down by security restrictions, since the > system bus has a default-deny policy and the "firewall" rules that allow > messages through will typically only match particular interfaces. > Allowing messages with an unspecified interface to match a rule with a > particular interface would be a security flaw, because the dbus-daemon > can't know how a service will interpret such a message. > > I think it's fine that (semi-)high-level APIs like > g_dbus_connection_call() don't allow omitting the interface - it's a bad > idea, and IMO the spec should have declared it to be undefined behaviour. > > If for some reason you really, really need to send a message with "no > interface", then I have two suggestions: > > * use lower-level API that doesn't protect you from shooting yourself > in the foot - g_dbus_message_new_method_call() and the > g_dbus_connection_send_message_with_reply() family > * redesign your D-Bus API so you don't need to do that > > Regards, > S > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
