bug#43252: 27.1; DBus properties lack type hints or overrides

[Michael Albinus]

Hugh Daschbach <hugh@ccss.com> writes:

Hi Hugh,

>> I need more testing and a cleanup pass.  I'll pass along a better
>> version when
>> I think it's ready for review.
>>
>> I've started a few "should fail" tests.
>
> I've made a bit of progress.  I have a few tests that fail.  There
> doesn't seem to be any type checking on property set.  But have a look
> and see if you concur that these are real errors.  I've attached a
> patch.

Well, before getting type information in dbus-event, it wasn't possible
for dbus-property-handler to know the types of values provided by
org.freedesktop.DBus.Properties.Set method calls. Therefore I've said,
that the type used in dbus-register-property shall be inherited. This
decision wasn't dictated by the D-Bus API, it was just an implementation
restriction.

Now, that the type information is preserved, I have abandoned this
restriction. You can register a property with any type, and you can
overwrite this property via an ofDP.Set call with a value of any other
type. This is not forbidden by the D-Bus API (but highly discouraged, I
guess).

> In addition, I see a failure in dbus-test04-register-method:
>
>> (equal
>>  (dbus-error "org.freedesktop.DBus.Error.ServiceUnknown" "The name 
>> org.gnu.Emacs.TestDBus was not provided by any .service files")
>>  (dbus-error "org.freedesktop.DBus.Error.ServiceUnknown" "The name is not 
>> activatable"))

Oops, yes. The intention of this check is to see, whether
org.freedesktop.DBus.Error.ServiceUnknown is reported (it is). The
additional explanation doesn't matter, and it seems to be different
depending on the D-Bus daemon implementation (I'm using Fedora 32).

So I've pushed a fix, which checks just for the D-Bus error name, w/o
the additional text.

> I'm starting to run out of ideas for additional tests. Suggestions
> welcome.

The major black hole seems to be dbus-introspect* tests. If you are
interested? I fear writing them will be boring, so I haven't done them
yet ...

OTOH, they are not the most important part of Emacs' D-Bus implementation.

> Cheers,
> Hugh

Best regards, Michael.