W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > August 2014

Re: Notes from meeting between Chrome and Mozilla folks

From: Bran, Cary <Cary.Bran@plantronics.com>
Date: Fri, 8 Aug 2014 23:01:22 +0000
To: Marcos Caceres <marcos@marcosc.com>
CC: public-web-bluetooth <public-web-bluetooth@w3.org>, Jeffrey Yasskin <jyasskin@google.com>, Vincent Scheib <scheib@google.com>, Shawn Huang <shuang@mozilla.com>
Message-ID: <D00A9B67.74972%cary.bran@plantronics.com>
My response may be over simplified but happy to elaborate further.

On 8/8/14, 3:19 PM, "Marcos Caceres" <marcos@marcosc.com> wrote:

>On August 8, 2014 at 6:12:40 PM, Bran, Cary (cary.bran@plantronics.com)
>> > I too agree with needing a way to accept a UUID as device
>> may come up with their own device specific services and the friendly
>> name for standard services makes sense to me.
>Ok, let's tease out a bit how people envision the custom service thing
>would work with the UUID. Can you provide a scenario and walk through it.
>What would be great to see would be:
>1. how does script request Custom Gizmo?

If I were writing a JS library for connecting to my Custom Gizmo -I would
know the UUID of my gizmo.  It would be nice if the APIs could provide the
ability to query the adaptor for available gizmos that support the UUID in
question.  This would not create a socket connection to the device,
instead it would query the devices for their supported services.  I assume
there would be an enumeration of gizmos that supported the same service
(similar to the case we have today with multiple cameras).

>2. how does the user select Custom Gizmo? (granting access)
I think this would be similar to the permissions window we see for other
device access (camera, microphone), once a user has chosen to use an
application that will make use of the gizmo and create a socket connection
to it. Once permission is granted, it could be on a per UUID service basis
(e.g. I have two heart rate monitors on and I give permission for the
first it implies consent to the second).

>3. how does script interface with Custom Gizmo? (send/receive data)

Script interfaces would use a socket connection to send/receive data
(event driven on the receive side) - something similar to the Google BT
APIs model would suffice.

>4. how does user stop page using Custom Gizmo? (revoke access)
>In the above, where does the UUID come into play? Just make up any old
>fake-looking code - it's just so we are all on the same page.

The UUID comes into play on the socket connection to the device, so it is
associated with the socket connection:

PLTLabsAPI.openConnection = function(device, callback){
   log('openConnection: opening connection for device ' +
   onSocketConnectionCallback = callback;

   chrome.bluetoothSocket.create(function(createInfo) {
                                PLTLabsAPI.socketId = createInfo.socketId;
                                PLTLabsAPI.device = device;
                                chrome.bluetoothSocket.connect(createInfo.socketId, device.address,
BR_PROFILE.uuid, onConnectDeviceHandler);})

The devices we are building have their own command/control APIs - we can
turn sensors on and off via proprietary commands sent over the socket
connection.  Perhaps the sensors that are enabled over the connection
could be characterized in a standard way that can be conveyed to the user.
 E.g. heart rate monitor (on), pedometer (off), accelerometer (on),
compass (off), etc.

I do have a working sample chrome packaged application that I wrote using
the dev channel BT apis for chrome to stream sensor data from one of our
prototype devices, I could share the code if that is of interest.



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at privacy@plantronics.com, and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com.
Received on Friday, 8 August 2014 23:02:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:52 UTC