What service/characteristic/descriptor browsing interface should we define? about web-bluetooth

[jyasskin]

1. The GATT wireless protocol defines (BT4.1 3.G.4) both a way to discover all primary services/included services/characteristics/descriptors (3.G 4.4.1, 4.5.1, 4.6.1, 4.7.1) and a way to discover a single service or characteristic given its UUID (3.G 4.4.2, 4.6.2). Android and MacOS provide interface functions for looking entities up given a UUID. Mac accepts a list of interesting UUIDs, which may allow it to optimize the Bluetooth radio better than a series of 1-UUID calls. If we insist on fully populating the tree on instantiation, or even using a GetAllServices() method, we may unnecessarily hurt performance and battery life.
2. The above also, I think, answers this point: yes, we should let developers access just the UUIDs they're interested in. For now, let's not provide [] access since [MapClass] appears to require a synchronous getter for all entries, so it would require us to fully populate the tree eagerly, and plain getter methods don't allow any type structure on their argument. Both would be somewhat ambiguous between forwarding to getCharacteristic and getIncludedService, although UUIDs are unique enough to produce a clear answer.
3. No, 4.4.2 says "The specific primary service may exist multiple times on a server", and one library gave the example of a device with multiple batteries, each of which exposes a copy of the same service. We could provide functions similar to querySelector vs querySelectorAll to provide the first vs all instances of a service.

Maybe we should use:

Promise<GATTService> getService((DOMString or UUID))
Promise<sequence<GATTService>> getAllServices(optional (DOMString or UUID or sequence<(DOMString or UUID)>))

which incorporates @marcoscaceres' suggestion to allow names for the standardized UUIDs. getService((DOMString or UUID)) would follow Android in returning the "first" instance of the specified service.

[jyasskin]

@armansito, I'm curious about your thoughts on the optimization described in (1). Specifically, I'm thinking that if a website connects to a device and calls getService(a_uuid), the UA can avoid doing a full service discovery and instead use the 1-round-trip Discover Primary Service by Service UUID procedure.

[armansito]

To be honest, I think the Web API spec shouldn't care, though if the UA wants to optimize and only discover specific services on demand, then it should be free to do so. In Chrome (or Chrome OS specifically), we currently discover all services on initial connection and keep a cache.

So, in general, I agree with adding a getService(uuid) and leaving it up to implementation to decide how that service is obtained (that is OTA for the first time or from a cache).