Re: Sketches of extensions to support Eddystone and resuming sessions

[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).

On Fri, Aug 7, 2015 at 11:01 AM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> Yep, that looks about right. Like I replied in the getDevices
> document, I'm not sure we want UAs to be in charge of sorting the
> devices list by recency of use, but web pages can certainly use that
> as their reconnection order.
>
> On Fri, Aug 7, 2015 at 3:48 AM, François Beaufort 🇫🇷
> <fbeaufort@google.com> wrote:
> > Thank you Jeffrey for sharing these sketches.
> >
> > I'd like to share also some code I wrote which helps me to get the full
> > picture: http://pastebin.com/dTrM48G8
> > This code features one way of doing Physical Web detection and handling
> > session resuming.
> > It is not necessarily "the" way to go but it gives a sense of what we're
> > trying to accomplish here.
> >
> > Let me know if that makes sense.
> >
> > On Thu, Aug 6, 2015 at 10:28 PM Jeffrey Yasskin <jyasskin@google.com>
> wrote:
> >>
> >> Hi Web Bluetooth CG,
> >>
> >> A couple folks have asked how Web Bluetooth will interact with
> >> Eddystone and how websites can handle reloads without showing another
> >> dialog. I have sketches of possible designs for this at
> >>
> >>
> https://docs.google.com/document/d/1jFCTyq84T2fLc8ZhxorTz3u_gCk59hp17EmkFgaDQ2c/edit?usp=sharing
> >> (Eddystone) and
> >>
> >>
> https://docs.google.com/document/d/1QLEi4lK4St3tS_EQEKqhTOn5Gi47sN5mUoLCm4tOyr8/edit?usp=sharing
> >> (getPairedDevices). I'm not sure the new interfaces will be in the
> >> first version of the Web Bluetooth spec or implementation, since I'd
> >> like to constrain that to the smallest interface that works for
> >> people, but if there's a lot of interest and agreement on the shape we
> >> want, I can pull them into the spec.
> >>
> >> Please look these over and let me know what you think, either with
> >> replies to this email or comments on the documents.
> >>
> >> Thanks,
> >> Jeffrey
> >>
> >
>
>