Should requestDevice automatically connect to the device?

[jyasskin]

Discovery and connection are separate steps in the Bluetooth spec and in most APIs that access Bluetooth. However, these APIs generally don't expose as compressed a discovery flow as this one, nor do they involve an "open-like" dialog where the user selects a device.

I don't know of a use for getting a handle to an un-connected device, but if you know of one please mention it here.

If there's a use, we need to expose that possibility. It's not clear whether we should expose it by having requestDevice() return an un-connected device regardless and making all developers call connect() explicitly, or by having requestDevice() default to returning a connected device, but with an option to override that default.

[shawnjohnjr]

Yeah, there is no need to return un-connected BluetoothDevice object.
The first time I saw requestDevice(), I thought the user only needs to select one device to connect with.
And what really bothers me is to handle the transition between different programs.
I think this really depends on how platform works. If user selects a Bluetooth Smart device which is filtered by UUID, and that device requires authentication. Browser needs to guide user to perform system-level interaction. User needs to open up Settings application and find BluetoothManger-like program to pair with. After pairing completed, how can Browser know when that specific Bluetooth Smart device get paired? I think Browser has to invoke GATT client connection after device paired automatically in order to optimize user experience. I'm not sure all operating systems expose API to let Browser perform a query the paired-device list. So, I'm confused about this use case.
And yes, if user tries to pair with the device from Setting program in the beginning, the problem will be solved. Then we probably need to define that "open-like" dialog contains devices that already paired or not-paired-yet.

Currently requestDevice() defines two behaviors--connect and discovery services, after that I assume it cached everything, and it doesn't provide discover service method. It doesn't give application refresh trees.
Suppose there is one Bluetooth Smart device with 3 sensors, when we connect with the device, only one sensor is being activated, so only one Thermometer Service shows up, and we only cache one service. I guess it's possible to activate other sensors and the device update service list again, in this case, the application may need to discovery service again.

[jyasskin]

I'm having trouble following how your comment after the first sentence relates to the subject of this issue. If it's a separate concern, could you open a separate issue?

[pzboyz]

I think the API should provide the programmer 2 options, [1] to get a list of known and paired devices and if they are inrange and connected, and [2] find nearby devices, which should be a list of different devices to [1], and then give the option to connect and pair with if needed.

[jyasskin]

@pzboyz, I don't see how that's related to the topic of this issue? If it's a separate suggestion, and is compatible with the security and privacy risks, could you file a new issue about it, with a justification?

[pzboyz]

Your last paragraph states it is not obvious what requestdevice() should return, I was stating it needs to return two types of lists of devices.

[jracle]

It's a bit hard for me to follow all the ideas proposed by @shawnjohnjr and @pzboyz, but I'd like to add my coins here as well.

For me, returning un-connected devices is preferred since we might want to retrieve device(s) and communicate with them later on in time. Suppose we have some control panel, we can stick with device name and AD uuids as a start; enumerating services requires connection, but we know those devices already are of interest, so we can keep enumeration on-demand while, say, opening device details. This agains saves wireless communication.

A second remark IMO is for coherency with function's responsibility (though highly subject to debate). I feel that providing un-connected devices is still as understandable as connecting automatically. After all, we have a connect() method which we would have to call in any case. If device has gone out of range, it would fail, as it would if popup appeared then device goes out of range, then user selects device, no?

Please also consider devices which expose services handled at OS level. My Logitech-bias make me focus to HID over GATT profile. We indeed have a couple of HID mice and keyboards for which pairing will be handled by OS (bluetooth) device manager. I think my concern meets @shawnjohnjr here; devices requiring encryption and authentication are to be looked into as well.

[jyasskin]

The idea is that a user might connect multiple devices to their control panel, but then not actually use some of the devices they connected? That'll make more sense once we add a way to reconnect to already-allowed devices without bugging the user again, a'la #31, but we do need to anticipate it in this API.

I agree that separating out connection makes the requestDevice() function's responsibility more coherent. I guess users can always write a wrapper if they notice they're always connecting.

If we separate the steps, we should consider making connect() return a Promise<BluetoothDevice> so that we can write:

  requestDevice([filters], {options}).then(device => device.connect()).then(actual_stuff);

instead of

  requestDevice([filters], {options}).then(device => {
    device.connect()
    return device;
  }).then(actual_stuff);

Of course, if we switch to connectGatt() like #22 might conclude, then that would naturally return a different interface and be chainable like this.

[pzboyz]

@jracle I agree with your thinking and rationale.

[jracle]

Thanks @pzboyz !

@jyasskin, the idea is to present all devices to the user with their basic information (once we have device name, we don't always need to connect to the device to fill a list view item). If user selects the device, then we can enumerate service(s) lazily.

@jyasskin it would be great that BluetoothGattDevice.connect() return Promise<BluetoothDevice> indeed..

[jyasskin]

Let's remove the connect() behavior from requestDevice(), rename it to connectGatt(), and have it return a BluetoothRemoteGATTServer that exposes the connected attribute and disconnect() andgetService*()` functions. I'll file a separate issue if the patch that does the first doesn't catch all the rest, since they're mostly independent from this issue.

By the way, @pzboyz, could you introduce yourself on the list?

[scheib]

@alainmanigat Asking this question is best done on https://stackoverflow.com/questions/tagged/web-bluetooth. Replying to an unrelated closed spec issue isn't a good method.