- From: Vincent Scheib via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Nov 2015 19:18:07 +0000
- To: public-web-bluetooth-log@w3.org
We should keep the implementation flexible, and not force queuing if the application doesn't desire it. 12:35 AM <perja> Hi, short question about web-bluetooth: I have a page that writes to a characteristic whenever a button is pressed (or actually a touch event), but if I click to fast I get the "GATT operation in progress"-error. Is it so that the page author is supposed to handle this with a queue or similar, or will the implementation do the queing? 1:12 AM <scheib> perja: Currently unspecified. We should pick and make it clear. Some devices may be fairly slow to accept a write. What should happen if the web page can generate write requests at 2 times the speed a device can process them? If the browser queues, should it pick any limit for how large the queue should get? An application can know if a queue of unlimited values is needed or if only 1 pending value needs to be queued and replaced if a newer value arrives. -- GitHub Notification of comment by scheib Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/188#issuecomment-159377957 using your GitHub account
Received on Tuesday, 24 November 2015 19:18:09 UTC