RE: Request for interested participants in an Health & Welness Web Apps W3C community group

While this is addressed to Jose, it really is based on a conversation I had with one of our API implementation teams recently and applies to anyone who wants to standardize on "an API for Bluetooth communication from a web page". Virtually none of this content is actually specific to Jose, and so, I'd hope that everyone reading it understand that it is meant to be generic. It is meant to be a friendly guideline for anyone who thinks they have a problem of the form "I want to use a Bluetooth device from a web page".

Jose wrote:
> ... we will take a look into WebSockets
> I have a glucosemeter that can send the data to any Bluetooth receiver using HDP data format,
> and my phone supports HDP bluetooth communication.

> But to send the data to my Personal Health Record I could not use a web application
> because there is no standard way to communicate the browser with the underlying
> bluetooth infrastructure to get the data from it.

Here's the *current* list of Bluetooth Profiles according to Wikipedia [1] *(not actually an authority on anything):
    1.1 Advanced Audio Distribution Profile (A2DP)
    1.2 Audio/Video Remote Control Profile (AVRCP)
    1.3 Basic Imaging Profile (BIP)
    1.4 Basic Printing Profile (BPP)
    1.5 Common ISDN Access Profile (CIP)
    1.6 Cordless Telephony Profile (CTP)
    1.7 Device ID Profile (DIP)
    1.8 Dial-up Networking Profile (DUN)
    1.9 Fax Profile (FAX)
    1.10 Generic Audio/Video Distribution Profile (GAVDP)
    1.11 Generic Access Profile (GAP)
    1.12 Generic Object Exchange Profile (GOEP)
    1.13 Hard Copy Cable Replacement Profile (HCRP)
    1.14 Health Device Profile (HDP)
    1.15 Hands-Free Profile (HFP)
    1.16 Human Interface Device Profile (HID)
    1.17 Headset Profile (HSP)
    1.18 Intercom Profile (ICP)
    1.19 LAN Access Profile (LAP)
    1.20 Object Push Profile (OPP)
    1.21 Personal Area Networking Profile (PAN)
    1.22 Phone Book Access Profile (PBAP, PBA)
    1.23 Serial Port Profile (SPP)
    1.24 Service Discovery Application Profile (SDAP)
    1.25 SIM Access Profile (SAP, SIM, rSAP)
    1.26 Synchronisation Profile (SYNCH)
    1.27 Video Distribution Profile (VDP)
    1.28 Wireless Application Protocol Bearer (WAPB)

Note that each individual profile requires distinct code at the application level (plus possibly support in lower stack levels).

Assuming that supporting a profile required *zero* code, there's still the issue of understanding whether sending/receiving data to/from a given device using a given profile is safe / should be generally available. Some devices for instance have poor Bluetooth stacks and will die if sent "interesting" input. Some devices also don't deal particularly well with e.g. "lots" of input. Should a browser randomly enable random web content to send such arbitrary data which could be used by that web content to deal damage to those Bluetooth devices? Note that it's incredibly unlikely that a user will ever be able to understand any security risks involved in such things. Part of designing web APIs is ensuring that the APIs generally are not dangerous. Another part is ensuring that an API is specific enough to solve a real problem and important enough to be widely implemented.

> I could build an app to do that or even create a plugin for phonegap to use a web app,

You could create a process which speaks WebSockets and speaks Bluetooth, and gateways a limited vocabulary between a WebSockets consumer (some web app), and a Bluetooth device (your glucose monitor).

> but, we would like that the API we would define to become a Recomendation.

I personally am not interested in having millions of Bluetooth specific APIs for each of the millions of potential Bluetooth devices that might be out there, especially if you're actually just using something like SPP (which if I've picked the right profile is basically just a stream protocol for sending and receiving arbitrary data).

Practically speaking, each SPP supporting device model or each physical device model with a physical serial port is unique and has a unique API footprint. Just as each modem supported a different portion of e.g. the Hayes command set[2]. Sure someone could make a minimal API which exposed some portion of Hayes (and in fact, there are probably a dozen, including TAPI, RRAS, and BTDUN), but what people generally are asking about isn't a generic "hello", it's something specific to an individual model, and it requires much more than just some limited standardized API.

> So, the API could be implemented by other people in other browsers or frameworks.

This doesn't seem particularly useful. You're welcome to provide the source for your WebSocket <-> Bluetooth gateway and encourage people to enhance it. It's unclear what value standardizing this provides. There are negatives to standards, one is that they can't really change, another is that vendors are forced to retain and maintain that code more or less forever.

Note that by implementing a WebSockets <-> Bluetooth gateway, any local application (or non local, depending on your WebSockets implementation) would be capable of talking to your device, so you aren't tying yourself to a single User Agent, just any user agent which supports WebSockets (of which we believe there will be many).

But if you do this, please keep in mind that it's your responsibility to protect the user's data. A web browser can't possibly understand and is not in the business of understanding health data. If you used XMLHttpRequest/RESTful-JSON, then it would be your responsibility to be aware of things like CORS [3]. For WebSockets, I don't know how security is managed, but again, it will be your responsibility to be aware that in making a gateway you are potentially enabling other processes beyond your control to access a device which has a sensitive purpose.

> Continua guidelines recommends to use IEEE 11073[1] data format for data gathering
> so I don't know sensors would use WebSockets for sending the information to the
> mobile phone.

As noted above, nothing requires you to send WebSocket data over the Bluetooth connection. You could use the WebSocket to send requests from a Web Application to a manager which then converts it into appropriate controls to be sent via Bluetooth to the actual device.

> I don't mind how the mobile phone gets data,

Good, you can leave that as Bluetooth, and we can leave it as an implementation detail not embodied in any standard.

> I am worried about an standard way to ask to my device from a web app
> the data that it has gathered.

Write a prototype implementation using WebSockets (or HTTP, whatever) which proxies to your Bluetooth device, and see how things go. Once you have done that and have some implementation experience, then, you can worry about standardizing retrieving that data. If you design things well, with the API for the WebSocket not tied too closely to individual Glucose monitoring devices, and supporting some amount of plugability, then people can plug in their own monitor proxies later for their own devices.

Note that nothing requires you to use WebSockets for this, you're free to set up a gateway that speaks classic HTTP and uses a RESTful (JSON?) API instead. Today it happens that "WebSockets" are the big buzzword, but if you prefer to use XMLHttpRequest w/ JSON and a local web server, that should be fine too.

[1] http://en.wikipedia.org/wiki/Bluetooth_profile#List_of_profiles

[2] http://en.wikipedia.org/wiki/Hayes_command_set

[3] http://www.w3.org/TR/cors/



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 29 June 2011 18:02:30 UTC