How to re-discovery service explicitly? about web-bluetooth HOT 5 CLOSED

It looks like the «Service Changed» characteristic, defined in BT4.1 3.G.7.1 provides Indications to bonded devices when there's a change to the set of services a device provides. The spec draft exposes these updates through the servicechanged event.

Given the requirement in BT that

If the list of GATT based services and the service definitions cannot change for the lifetime of the device then this characteristic shall not exist, otherwise this characteristic shall exist.

is there a need to provide a polling-based interface?

from web-bluetooth.

There certainly should not be a polling-based interface. Service caching on the client-side inherently requires bonding and the presence of the "Service Changed" characteristic. The client is required to initiate service, characteristic, and descriptor discovery within the handle range that is contained in the indication PDU, if such an event is received from the peripheral.

The onServiceAdded, onServiceRemoved, and onServiceChanged events should be called as a result of the an indication from the "Service Changed" characteristic. So, as far as the API behavior goes, when such an indication is received, rediscovery should be automatically handled and the onService* events should be called accordingly.

from web-bluetooth.

Looking at the spec (which may not match the actual devices), it looks like

1. For non-bonded devices, the "Service Changed" characteristic is still indicated and allows caching within a single connection. For bonded devices, it allows caching across connections. That's "For clients that do not have a trusted relationship with the server, the attribute cache is valid only during the connection. Clients without a trusted relationship shall receive an indication when the service change occurs only during the current connection." in 3.G.2.5.3.
2. If the "Service Changed" characteristic is missing, that means the set of service definitions can't change, so caching always works. "If the list of GATT based services and the service definitions cannot change for the lifetime of the device then this characteristic shall not exist, otherwise this characteristic shall exist."

The one thing that worries me about this is that it doesn't seem compatible with an optimization described in 3.G.4.4.2, "Discover Primary Service by Service UUID". If a client finds all current services with UUID 1234, and then a new instance of the 1234 service is added, they'll get a ServiceChanged indication for the new range, but no indication that it's the service they care about. But maybe that's just a requirement to run "Discover All Primary Services" on any range mentioned in the ServiceChanged indication that's not strictly inside a known service.

I'll close this with the conclusion that we don't need a way to explicitly re-discover services, and that the UA just needs to keep its cache up to date. Feel free to reopen with more discussion though.

from web-bluetooth.

I think for the purposes of this web API, I don't think that "Discover Primary Service by UUID" is necessary: the underlying implementation should just discover all services and cache them.

In the case you're describing, the central can run the "Discover Primary Service by UUID" procedure inside the handle range that it receives in the indication from the Service Changed characteristic. This way it can find out if a new service with the desired UUID has been added.

But overall, I agree with your conclusion.

from web-bluetooth.

I agree with your conclusion, thanks.

from web-bluetooth.