Should we have onCharacteristicAdded/Removed and onDescriptorAdded/Removed event handlers? about web-bluetooth

[jyasskin]

@armansito since that's copied directly from the Chrome API.

The DescriptorEvent was used for DescriptorValueChanged, which I removed in #18. I'll leave it for now in case another descriptor event comes back.

[armansito]

This is an idea that I toyed with while designing the Chrome API as well. What I finally decided was that it was more intuitive to fire a single event (onServiceAdded) at the end of the initial discovery of all characteristics/descriptors than to have a succession of onServiceChanged/onCharacteristicAdded events.

Similarly if an existing service definition changed and we received a "Service Changed" event, I find that it is more intuitive to fire a single onServiceChanged event after we rediscover all characteristics and descriptors and have the application reprocess all of them in a single event.

So I suppose we should clarify that onServiceChanged is reserved for indications from the "Service Changed" characteristic?

[shuangMoz]

So I guess this is what happened as ServiceChanged:
(1) GATT server sent ServiceChanged indication
(2) bluez bluetooth stack received ServiceChanged indication and automatically start re-discovery services (call gatt_discover_primary?)
(3) onServiceChanged gets called once for a service after all of its characteristics and descriptors have been discovered
Question: Shall we expect BluetoothGATTServiceSequence in ServiceEvent? Maybe there will be two or more services changed?
I'm not sure this is a good question but I'm confused.

[armansito]

Pretty much. If two or more services changed, then we either send multiple onServiceChanged events, one for each service that was modified, or we have a single onServicesChanged that takes in a BluetoothGATTServiceSequence; either way is fine. If any services were removed or added, then we send onServiceAdded and onServiceRemoved events for them.

Note on BlueZ: With the current BlueZ APIs that we're trying to deprecate (the code in attrib/), we would call gatt_discover_primary. What BlueZ will do to propagate this information is something do decide. In the Chrome OS specific implementation, I simply remove all services and rediscover everything after a Service Changed indication. This is definitely a stop-gap solution. I'm still revising the proposed D-Bus API and in the process of implementing it for upstream.

[shuangMoz]

And we don't have to call onCharacteristicValueChanged if the Characteristic is << ServiceChanged >> , even if it's an indication, right?

[armansito]

It depends. If we decide to expose the << GATT >> service then we should probably allow an app to call BluetoothGATTCharacteristic.startNotifications on the ServiceChanged characteristic (even though apps wouldn't be permitted from actually disabling indications from it). In that case, we would send an onCharacteristicValueChanged event. That said, there isn't much the app can do with it.

If we're blacklisting the << GAP >> and << GATT >> services and hiding them from the applications, then we wouldn't call onCharacteristicValueChanged. (I'm leaning more towards this).

[shuangMoz]

In that case, we would send an onCharacteristicValueChanged event. That said, there isn't much the app can do with it.

The reason I asked is because the application already get information updated from onServiceChanged/onServiceAdded, and it looks like we duplicate information again, and <<ServiceUpdated>> Char comes with attribute handles, the application cannot use the handle value directly to do anything.

If we're blacklisting the << GAP >> and << GATT >> services and hiding them from the applications, then we wouldn't call onCharacteristicValueChanged

This is ongoing Issue #24

[armansito]

You're right, in that it's redundant. Then again we would only do this if the application specifically requested to get notifications from that characteristic.

We can discuss this as part of issue #24. I think as far as this issue goes (whether to add Added/Removed events for characteristics/descriptors), I think we all agree that a single onServiceChanged event is sufficient?

[jyasskin]

It sounds like it makes sense to expose the ServiceChanged event directly and not make the UA parse it into a cloud of CharacteristicAdded, CharacteristicRemoved, DescriptorAdded, and DescriptorRemoved events. Websites can use the Characteristics' and Descriptors' instanceIds to identify precisely which ones have appeared or disappeared. I'll close this in a couple days if nobody's spoken up by then.

[yrliou]

For the onCharactersticAdded/Removed, onDescriptorAdded/Removed, I agree the conclusion here, a single onServiceChanged should be sufficient.
We can discuss further about service changed characteristic in issue #24 as @armansito suggested.
Thanks!