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

[Michael Albinus]

Hugh Daschbach <hugh@ccss.com> writes:

Hi Hugh,

>>> Reading the BlueZ D-Bus GATT API description, you seem to need only
>>> basic types and arrays of basic types as properties. So I will start
>>> adding arrays of basic types. Other, more complex compound types
>>> will follow later.
>
> That's mostly true.  There is another BlueZ interface (advertising)
> that take a byte keyed dictionary.  It isn't obvious from the
> documentation
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt.
> But the Manufacturer ID described mentioned in the ManufacturerData
> dictionary description is a byte value.
>
> The property table in the BlueZ source code looks like:
>
>       { "ManufacturerData", "a{qv}", get_manufacturer_data,   NULL,
>                                               manufacturer_data_exists
>                                               },
>
> (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/client/advertising.c#n465)
>
> It isn't clear that there's a commitment to support such a data
> structure.  The DBus info page says "Every dictionary entry has a
> string as a key".

Looks like this has been extended to "Every dictionary entry has a
basic type as a key".

Anyway, my today's commits shall support now all compound types for properties.

> I haven't been able to verify property signatures programatically. I
> have turned on dbus-debug and verified signatures reported by the
> message formatter.  I assume introspection is in the queue.  With
> introspection, we could extend the tests.

I'm no more convinced that introspection is the way to go. What if there
aren't introspection data?

Maybe one could run two processes in parallel to the tests:

--8<---------------cut here---------------start------------->8---
dbus-monitor --session "sender=org.gnu.Emacs.TestDBus"

dbus-monitor --session "destination=org.gnu.Emacs.TestDBus"
--8<---------------cut here---------------end--------------->8---

It shall be possible to analyze their structured output.

> I assume I shouldn't care about tests that fail with debug turned on.

Yes. However, dbus-debug on let's *all* dbus-error errors through, both
internal errors, and the ones arriving from incoming D-Bus error
messages. Sometimes, one wants to see the latter only. So I have added a
defcustom dbus-show-dbus-errors which allows to pass only the incoming
error messages. See the changed dbus-test05-register-property for examples.

> Thanks again,
> Hugh

Best regards, Michael.