Linux-Bluetooth Archive on
 help / color / Atom feed
* Flag for specifying write type to WriteValue in gatt-api.
@ 2019-01-31 16:15 Emil Lenngren
  2019-01-31 17:03 ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 5+ messages in thread
From: Emil Lenngren @ 2019-01-31 16:15 UTC (permalink / raw)
  To: Bluez mailing list


I was looking through the quite lengthy discussion at 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

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-31 16:15 Flag for specifying write type to WriteValue in gatt-api Emil Lenngren
2019-01-31 17:03 ` Luiz Augusto von Dentz
2019-01-31 17:46   ` Emil Lenngren
2019-01-31 17:55     ` Luiz Augusto von Dentz
2019-01-31 18:09       ` Emil Lenngren

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ \
	public-inbox-index linux-bluetooth

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox