search

flyweb / spec

Web API specification for enabling web pages to publish local-area servers
105 stars 3 forks source link

Physical Web and FatBeacons #10

Open jokeyrhyme opened 8 years ago

jokeyrhyme commented 8 years ago

There are some aspects of Google's FatBeacon that overlap somewhat with FlyWeb:

Has there been any collaboration between Google and Mozilla teams in this area? Is that something that is worth considering?

kannanvijayan-zz commented 8 years ago

We've spoken with the Physical Web team, communicating ad-hoc for about a year now. There's potential for collaboration here, but we need to think it through well.

One way to think about FlyWeb may be to envision it as a "self-directed" physical web URL - the URL somehow refers "back to" the device that broadcast it, instead of a plain internet URL. Making this work would require some browser support to identify these special URLs properly.

Alternatively, one could envision Physical Web as a "discovery frontend" for FlyWeb. FlyWeb's core pieces are a local-area web server, and a way to discover them. We're using mDNS (Bonjour) to advertise, but that could be changed.

The biggest challenge we face is actually Bluetooth related. FlyWeb needs a good, fast transport layer to communicate with the local server. TCP sockets over Wi-Fi for example, are great - they can support several mbps bitrate, letting us easily do webby stuff on top of it.

Bluetooth LE doesn't support the bitrate we need to shuttle modern HTTP/JS/CSS/Images/etc. It's like 5k/s. We can use BLE as an advertising layer, but HTTP transport has to be on some other medium. We've done investigations into using classic Bluetooth RFCOMM sockets for the HTTP tunneling (and it seems to work pretty well - BLE to advertise, BLE GATT for service metadata, and BT RFCOMM for primary transport).

The issue is that good APIs for BT RFCOMM don't exist on iOS, which means we can probably never implement that solution on iPhones. The mDNS + Local IP network approach has more restrictions (need a local network, can only discover things on the local network), but the hardware and API support for it is solid across all platforms and all devices.

So, yeah. We've been trying to figure out a good way to interact with Physical Web because as you point out, there are definitely use case overlaps between that project and FlyWeb. We still need to see what can be done about that, though.