Michael Albinus writes:

> Michael Albinus <michael.albinus@gmx.de> 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".


> I have pushed my recent work to master. dbus-register-property,
> dbus-get-property, dbus-get-all-properties and
> dbus-get-all-managed-objects shall work now for your byte
> array. dbus-set-property will follow tomorrow, as well as other 
> compound
> types but array.
>

With your latest work, I have successful tests for byte arrays, 
string
arrays, object arrays, boolean arrays, and string keyed 
dictionaries.

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 assume I shouldn't care about tests that fail with debug turned 
on.

WRT byte keyed dictionaries, I've attached a failing test.  I 
don't know
if you want to look at it or not.

Still waiting for a response from assign@gnu.org.  I assume a 
delay of a
few days is to be expected.

Thanks again,
Hugh