Download pages direct from beacons

[mofosyne]

If we are connecting to a beacon to control say... a quadrocopter, via downloading a page from the web. Then why not just also give the ability to download the actual page from the beacon itself on request, in addition to the standard periodic url broadcast?

This would be very handy when the page is not very complex (e.g. a cheap RC car remote. TV remote). Even if it's somewhat slower than mobile internet, it has the advantage of reliability and not needing to pay for webhosting.

You can speed this up via compression, or caching. Compression means shorter transmission time, so more responsive page loading. Caching means instant access if frequently used (e.g. you play with RC cars or TV every day)

---

And hey, it might be nice if people start learning to cram code into smaller sizes like the Atari Console Game days.

[scottjenson]

Agreed, it is an interesting idea, it's just much much harder. I'm concerned that:

1. It's much slower (unless the page is trivial as you say, but not everyone is as good as you)
2. It's much harder (storing your page into a beacon is tricky, makes beacon more expensive)
3. It's only 1:1 (multiple people can't use your beacon at once)
4. It's much harder to update (compared to a web server)
5. It makes the phone client more complex

Now before you fire back, I'm not saying we shouldn't do this, I'm just saying these issues just deprioritized it, we have so many other issues to solve to get the "V1 version" of this product out the door that we just got to work on the general issues at hand.

To be honest, I still think a solo beacon like this is far less useful than you'd expect, my guess is that the inability to update the webpage is going to it's biggest weakness. However, do let us know more, happy to discuss this further and see if there is something simple we could do.

[mofosyne]

Fair enough. I totally agree on the need to at least get everyone onboard with an achievable goal first. Especially considering the difficulties of getting the entire internet community to work together as a herd of cats.

At the very least, it should be mentioned occasionally (As an extension of the "direct connect" concept perhaps) as a possibility in the documents so people don't forget about it. This is especially considering the speed of technology developments within a decade, which may hopefully make your five points moot.

In terms of inability to update, its a similar issue to normal appliances, where you need to do firmware updates. At the very least, it just means you are forced to use the url method (Or make do without the update), if the page is held in rom memory. But at best, the physical web specification could provide a standardized method to update the pages as permitted. Again these are all speculation until we can solve the more pressing five points you mentioned.

---

Hmmm... on a side note. Is wifi direct a potential possibility? Transferring via wifi direct seems pretty fast with files. Then again, it wouldn't be as cheap as a BLE beacon. (On the other hand, that might not matter to a vending machine). ( Just a thought )

[scottjenson]

One possibility is to wait for JS BLE to come to the browser (Chrome is working on this now). This would allows a tiny JS loader to be on the beacon page which could then connect to web, check for new update and use JS to download/update the beacon image.

As to wifi direct, it's not looking really healthy right now, their sign up/joining process is much more restrictive and it's shut down most experimental development. We do have support for mDNS over standard Wifi, that's easier to download but opens up the possibility to a device that is already got network connectivity so it could auto update itself. However, with wifi around, why not just download the page?

[mofosyne]

true true. I guess we are at the mercy of wifi for this particular
convenience. Let's just shelve this for now, but with a short mention of it
in the document.

On Fri, Jun 12, 2015 at 11:59 PM, scottjenson notifications@github.com
wrote:

One possibility is to wait for JS BLE to come to the browser (Chrome is
working on this now). This would allows a tiny JS loader to be on the
beacon page which could then connect to web, check for new update and use
JS to download/update the beacon image.

As to wifi direct, it's not looking really healthy right now, their sign
up/joining process is much more restrictive and it's shut down most
experimental development. We do have support for mDNS over standard
Wifi, that's easier to download but opens up the possibility to a device
that is already got network connectivity so it could auto update itself.
However, with wifi around, why not just download the page?

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[scottjenson]

That's a fair request. Keeping this issue open until I find a good place to insert this comment.

[mofosyne]

Not a problem. Btw a little thought that I'm not sure if it deserves it's
own issue. You know how you have NFC tags that can emit NDEF messages? I
wonder if there is any advantage to implementing something similar but at a
non contact distance like BLE etc...

I was imagining one that emits a beacon message where their advertisement
packet is a manifest of the message it contains (e.g. NDEF). Or it can
transmit the full message over a period of time (But you need to hang
around to get the full message). Of course if interested, you can poke to
broadcast the full content.

If it's a valid concept to explore, then I'll could make a separate issue
to spark a wider discussion. Else I could just delete this message.

On Sat, Jun 13, 2015 at 1:51 AM, scottjenson notifications@github.com
wrote:

That's a fair request. Keeping this issue open until I find a good place
to insert this comment.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[pzboyz]

If the beacon support IPSP, then the beacon could serve up a webpage too directly using normal methods

[scottjenson]

Sorry IPSP?

[pzboyz]

Internet Protocol Support Profile, details here, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307 essentially it is 6lowPAN over BLE and follow https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/ to implement it.

[scottjenson]

Very cool, I'd never heard of it. It's so new, in fact, that a casual web search for IPSP can't even find it. This is clearly a very interesting technology and opens up all sorts of possibilities. The key issue is adoption as both side of the connection have to support it. Currently no phones do so it's a bit of a mute point. As soon as phone adoption gets higher, we should clearly look at this.

[mofosyne]

Whoa, thank you pzboyz for the information. Maybe this isn't as too far
fetched then. Definitely would be interested to see where that goes.

But yea, for now just note it down, but also mention the existence of "Internet
Protocol Support Profile" as a potential approach for this.

On Sun, Jun 14, 2015 at 12:05 AM, scottjenson notifications@github.com
wrote:

Very cool, I'd never heard of it. It's so new, in fact, that a casual web
search for IPSP can't even find it. This is clearly a very interesting
technology and opens up all sorts of possibilities. The key issue is
adoption as both side of the connection have to support it. Currently no
phones do so it's a bit of a mute point. As soon as phone adoption gets
higher, we should clearly look at this.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[scottjenson]

Well, if I can be a bit opinionated here, my concern is that this is a classic BT profile and not built in. The historical hit rate on profiles is pretty spotty: either it's never supported or it if is, it's done so poorly that compatibility is low. There is a certain 'profile fatigue' that exists in the BT classic community (there are dozens now to choose from) so let's just say that while the concept is amazingly cool (and I fully support it) the odds of it really making it to wide (and most importantly compatible) adoption seem unlikely (which is sad).

[pzboyz]

The other option, I thought of while walking around this afternoon, is to use FTP or GOEP, most phones and laptops already know how to do FTP, instead of having a device serve a webpage, have that page be stored in a directory \webthing\thisthing.htm plus associated *.png files, etc in the same webthing folder needed by thisthing.htm. Given support for FTP is already widespread, adoption will be quicker.

[scottjenson]

FTP is widely supported but I'm guessing that the problem with be IP over a BTL connection. That isn't supported yet.

But let's just say that we can pull this off, this still means that it will be a 1:1 only experience. If you're in a Mall with dozens of people around a kiosk, they'll have to wait in line to be able to see the page.

The main reason we went with this "URL in the Ad Packet" approach is that it is connectionless, like UDP, it can broadcast to an indefinite number of people. (the same can be said for mDNS over wifi btw) If they are in range, they can get it.

We've brainstormed lots of ideas but everything we say "and then you connect to the beacon" we start getting nervous. This clearly makes sense when you are interacting with it (like a vending machine) but if we want things to, as a starting point, serve up a web page, we very much want that to be a 1 to many mechanism if at all possible.

[pzboyz]

Many of the BLE chipsets available now can support sending adverts and handling 2 or 3 connections, for most normal use case, this seems to be sufficient. You have to choose the advertising periods and connection intervals carefully but it can be done.

[stephrieger]

@scottjenson do you have a link for the Chrome JS BLE initiative? Can't seem to find anything online.

[mmocny]

https://www.w3.org/community/web-bluetooth/

On Sun, Jun 14, 2015 at 5:13 AM Stephanie Rieger notifications@github.com
wrote:

@scottjenson https://github.com/scottjenson do you have a link for the
Chrome JS BLE initiative? Can't seem to find anything online.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[scottjenson]

you can also follow the group discussion here:
https://lists.w3.org/Archives/Public/public-web-bluetooth/

[scottjenson]

as this thread has gone quite, I'm going to close. Please feel free to add/reopen if there is more to discuss.