DBus Specification questions

[Simon McVittie]

On Thu, 02 Apr 2020 at 22:14:53 -0400, Felipe Gasper wrote:
> > On Apr 2, 2020, at 8:37 PM, Thiago Macieira <thiago at kde.org> wrote:
> > On Tuesday, 31 March 2020 00:07:02 -03 Robert Middleton wrote:
> >> 2. Even though it is valid to have a METHOD_CALL without an interface,
> >> is it valid to disregard messages that don't have an interface, or
> >> should an effort be made to do something with the message?  Would it
> >> be valid to return an error in this case?
> > 
> > Disregarding or returning an is not correct. You should match to a method that 
> > one of the interfaces provides. If more than one matches, it's unspecified 
> > which one gets called.
> 
> Out of curiosity, is it also legit to error in this circumstance?

To be completely clear about this, there are three possible situations
for a method call without an interface (let's say the client calls Foo()
with no interface specified):

1. The object in the service does not implement a method named Foo, in any
   interface.

2. The object in the service implements com.example.MyInterface.Foo, and no
   other methods named Foo.

3. The object in the service implements more than one method named Foo,
   for example com.example.Interface1.Foo and org.example.Interface2.Foo.

My understanding is that your question is about (2.), but I'm going to
address (1.) and (3.) first, because (2.) is a special case of (3.).

For (1.), the only correct thing to do is to reply with an error,
probably UnknownMethod.

For (3.), I think the D-Bus Specification has always allowed any of:

    - choose one interface or the other with a heuristic;
    - choose one interface or the other completely arbitrarily;
    - return an error saying that the call was ambiguous

and it's up to you which one you choose.

The D-Bus Specification does not say anything particularly clear about
what should happen in (2.). The original intention seems to have been
that the message would, deterministically, get delivered and processed
as though it had been directed to com.example.MyInterface.Foo, and
until https://bugs.freedesktop.org/show_bug.cgi?id=68597 in 2013, the
specification required this (although some implementations, like GDBus,
ignored that requirement and returned an error anyway).

I personally think it's entirely reasonable to implement (2.) by returning
an error without even attempting to deliver the message, like GDBus does.
In fdo#68597 I relaxed the spec so that it does not specifically forbid
this (after which GDBus was considered to be a correct implementation).

The D-Bus Specification strongly recommends that clients always put an
interface in their method calls, which sidesteps this whole mess.

If your D-Bus implementation is used for a service that has legacy clients
that do not follow the recommendation in the D-Bus Specification,
you are likely to get bug reports/feature requests asking you to
dispatch the method call to its only implementation. You can either
close those as "won't fix", or recommend working around those clients
by using lower-level APIs that ignore the interface field (as in
https://bugzilla.gnome.org/show_bug.cgi?id=706675), or implement the
behaviour that was required before 2013.

    smcv