MIME-Version: 1.0
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Thu, 31 Jan 2019 17:15:35 +0100
Message-ID: <CAO1O6scUuK1K+zLjyQA12HtY9nNdR=Q8MeuruC2GKvaJPH0knA@mail.gmail.com>
Subject: Flag for specifying write type to WriteValue in gatt-api.
To:     Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

I was looking through the quite lengthy discussion at
https://github.com/WebBluetoothCG/web-bluetooth/issues/238 on the
issue that in Web-Bluetooth, only a single "write value" API is
available, causing Web-Bluetooth to decide on its own if Write With
Response or Write Without Response should be used, in case both are
supported by the characteristic.

But in the Bluetooth spec about Write Without Response:

"This sub-procedure is used to write a Characteristic Value to a
server when the client knows the Characteristic Value Handle and the
client does not need an acknowledgement that the write was
successfully performed."

Basically, it says it's up to the client/application to decide if an
acknowledgement is needed or not, and hence it's the app that should
decide if Write With or Without Response should be used. The "client"
can't mean a bluetooth stack here since it can of course not know if
an acknowledgement is needed or not.

I noticed that according to gatt-api.txt, BlueZ has the same
limitation in the WriteValue method, in that the stack chooses the
write type "arbitrarily" if both write types are supported (or really
the Write With Response is chosen, which might cause unwanted
latency). Therefore I suggest that an option should be added to the
WriteValue method, for example "write-without-response" (bool) to
force Write Without Response.

Note how iOS has a write type parameter to the write method, and
Android has a write type property you set before you execute the
write.

I see that it might be possible to achieve the same result with
AcquireWrite -> write to socket -> release but that wouldn't be a good
solution for bluetooth stacks built on top of BlueZ that would like to
differentiate between the two write types (such as Web-Bluetooth)
since AcquireWrite can fail, for example if two apps write the value
at the same time (I guess the lock is exclusive?). It also seems like
unnecessary overhead to open and close sockets.

/Emil