- From: Emill via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Sep 2016 19:39:27 +0000
- To: public-web-bluetooth-log@w3.org
How do you mean that an operation is retried? The request is sent to the remote device and then it responds either with success (promise resolves) or some error code (promise rejects). The only problems that can happen are that either the link gets disconnected or the GATT timer specified by the BLE standard of 30 seconds times out (in that case the link is disconnected as well). Or that the underlying bluetooth stack bails out and crashes but then you're probably out of luck anyway. Haven't seen that however as of yet regarding GATT operations on the common platforms. On the GATT level you can't abort a request. Even if you for some reason want a shorter timeout than 30 seconds you are not allowed to send a new request until the previous one is complete. So in practice a custom timeout doesn't mean anything at all than basically notifying that the operation has still not yet completed. Nordic's example seems kind of strange that they give the ability to cancel enqueued requests not yet sent. That is really something you would like to do on the application layer, if you want to do that at all. I'd like to see a use case here. I think that if you must decide what to send next depends on the result of some operation, then you should wait until the operation completes and then resume rather than enqueuing lots of operations and then remove them from the queue if some operation didn't return what you wanted... -- GitHub Notification of comment by Emill Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/188#issuecomment-249284073 using your GitHub account
Received on Friday, 23 September 2016 19:39:34 UTC