Generic peripherals, was, Re: Notes from meeting between Chrome and Mozilla folks

On August 8, 2014 at 7:02:18 PM, Bran, Cary (cary.bran@plantronics.com) wrote:
> My response may be over simplified but happy to elaborate further.
>  
> On 8/8/14, 3:19 PM, "Marcos Caceres" wrote:
>  
> >
> >
> >On August 8, 2014 at 6:12:40 PM, Bran, Cary (cary.bran@plantronics.com)
> >wrote:
> >> > I too agree with needing a way to accept a UUID as device
> >>manufactures
> >> 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.

Ok, this is what I am a bit worried about. Targeting specific Gizmos is bad, and this is why: Imagine someone targets "Mozilla Mouse" instead of a "Mouse". This would cut anyone (intentionally or unintentionally) out of using a particular site or service - even if they have hardware that would work.  

What we want is for websites to be able to talk to any hardware that does what the user needs. If that is a heart rate monitor, it should not be "Mozilla's and Nike's Heart Rate Monitors only" - it should be *any* HR monitor. The same with Custom 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. 

ok, sure. But the adaptors could still just be strings, right?

> 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 ' +
> JSON.stringify(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);})
> ;};

What if you had gotten back an object that has all that already established. That way, you don't need the ID at all. 

like (adapted from the Streams API):

navigator.bt.requestDevice().then( (device) => {
    var stream = new ReadableStream({
    start(enqueue, close, error) {
      device.ondata = event => {
        if (!enqueue(event.data)) {
          device.readStop();
        }
      };
      device.onend = close;
      device.onerror = error;
    },
    pull() {
      device.readStart();
    },
    cancel() {
      device.readStop();
    }
}).then(read);


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

Sharing that code would be awesome. We could then prototype/shim this API on top to make sure it still works.

Received on Monday, 11 August 2014 19:14:05 UTC