Re: Sketches of extensions to support Eddystone and resuming sessions

On Fri, Aug 7, 2015 at 7:23 PM, Vincent Scheib <scheib@google.com> wrote:

> [Moving this discussion to the email thread, as it's a bit larger than
> fits in the doc.]
>
> scheib:
>>> The API should return the device ID rapidly, without waiting to see if a
>>> discovery can verify that the device is in proximity and known to the
>>> Adapter. Perhaps the ID is returned by returning a BluetoothDevice object,
>>> but in that case additional data is bundled: name, deviceClass, UUIDs.
>>> Should the Browser persist those and provide them speculatively presuming
>>> they haven't changed?
>>> It may be simpler to return simply IDs, and have getDevice(DOMString) be
>>> called later which would then perform discovery.
>>
>>
>
>> Jeffrey Yasskin:
>> Yes. I'm currently imagining that none of these would do anything with
>> the BT radio. They'd return cached data from the last time the browser saw
>> the device. Do you think saving that cached data is too expensive?
>> The webapp has the option of saving the set of IDs it's seen, so I don't
>> think there's a lot of use in a getDeviceIDs() function that just returns
>> the IDs. Sure, that'll take revocations into account, but so will the next
>> getDevice(id) call. The key here is getting the Device objects back.
>> We should also eventually add a function to request the set of
>> available/nearby devices, but I don't know what that should look like yet.
>> I'm inclined to let folks set an "auto-connect" bit on the device itself,
>> and then they'll get notified when the connection happens, which means the
>> device is nearby. We should try to avoid doing a full scan to get this
>> information: that doesn't take advantage of BT controllers' power-efficient
>> connection whitelist.
>
>
> I'm concerned about caching e.g. the UUIDs and adData - It's concerning to
> me that the data may be too stale - it may have been months or years since
> it was captured.
>
> The argument that a site can cache IDs is valid. The argument cuts both
> ways though, if sites can cache IDs, they could cache the rest of the
> information as well.
>
> We would offer them to the site as a convenience, because there's a good
> chance many useful apps could be implemented without persisting any other
> data. I'm not seeing an obvious answer, it's a convenience argument. My
> bias is for the simplest mechanism that offers the convenience, (just
> provide IDs), and my next preference would be to not build any caching into
> the API - let sites use a storage option instead, and only provide
> getDevice(id).
>

When I said "none of these would do anything with the BT radio", that
included getDevice(id). I now realize it's not what I put in the
document—"get the BluetoothDevice representing" does radio work—but I can
fix that when there's agreement on a particular behavior.

My goal here is to give developers a BluetoothDevice object for a device
they've previously seen. My instinct is that it'd be useful to let
developers have a BluetoothDevice object even if it's not in range or
hasn't been seen recently, which means getDevice(id) shouldn't try to ping
the object. We could drop most of the fields from the BluetoothDevice if
we're worried about them being stale, but the important thing is to get an
object handle with which to make method calls.

There's another option where we provide a
navigator.bluetooth.connectDevice(id), which rejects if the site doesn't
have permission but otherwise waits until the device is connectable and
then refreshes the fields and returns the device. I think I'd rather make
this a method on the BluetoothDevice than a free function, but the free
function would work.

Jeffrey