From: Mat Martineau <mathewm@codeaurora.org>
To: "Ganir, Chen" <chen.ganir@ti.com>
Cc: Claudio Takahasi <claudio.takahasi@openbossa.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
bgix@codeaurora.org, ingas@codeaurora.org
Subject: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications
Date: Thu, 27 Oct 2011 00:16:45 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1110270003090.30044@mathewm-linux> (raw)
In-Reply-To: <7769C83744F2C34A841232EF77AEA20C01DCAA9265@dnce01.ent.ti.com>
Hi Chen -
On Wed, 26 Oct 2011, Ganir, Chen wrote:
> Hi.
>
> Here's my proposal for some modifications to the existing attribute-api.doc file.
>
> These additions include :
> 1. Support for more properties, such as writable, readable, notify
> 2. Remove Value from the properties, and handle write/read with specific functions. This was done since currently the value is only read once from the server, and there is no way to refresh the value using the dbus API. In addition, the value can be written in multiple ways (we currently support write with response and write without response, but future write methods include write reliable and write signed, which may be required by profiles in the future).
>
> Here's the diff from the current docs/attribute-api.txt file :
>
> ---->8---------------
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 98d7f30..fbc6957 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -112,6 +112,17 @@ Methods dict GetProperties()
>
> Possible Errors: org.bluez.Error.InvalidArguments
>
> + array{byte} ReadValue()
> +
> + Read the value of the characteristic.
> +
One aspect of the current client implementation is that it caches the
read values within bluetoothd. Do you prefer to completely eliminate
that storage and always have ReadValue fetch from the remote device?
If there's still a use case for locally cached values (maybe there
isn't), a "method" parameter could specify the source of the data. It
could also provide some future-proofing for ReadValue.
> + int WriteValue(array{byte} value, int method)
> +
> + Write the value of the characteristic, with specified method :
> + 0: Write without response. Always return 0.
> + 1: Write with response. Return server response code.
> + Other write methods will be added in the future.
> +
This addresses the shortcomings we saw with SetProperty, and also
gives options for the future - seems like a great idea to me!
> Properties string UUID [readonly]
>
> UUID128 of this characteristic.
> @@ -142,15 +153,58 @@ Properties string UUID [readonly]
> uint16 | Description: Description of the characteristic defined
> | in a high layer profile.
>
> - array{byte} Value [readwrite]
> -
> - Raw value of the Characteristic Value attribute.
> -
> string Representation (of the binary Value) [readonly]
>
> Friendly representation of the Characteristic Value
> based on the format attribute.
>
> + boolean Broadcast [readwrite]
> +
> + Indicates whether this characteristic is broadcasted or not.
> + If GATT Server Characteristic Configuration descriptor
> + is not available for this characteristic, or if the characteristic
> + properties do not allow this, writing to this property is not
> + allowed.
> +
> + boolean Indicate [readwrite]
> +
> + Indicates whether this characteristic is notified or not.
> + If GATT Client Characteristic Configuration descriptor
> + is not available for this characteristic, or if the characteristic
> + properties do not allow this, writing to this property is not
> + allowed.
> +
> + boolean Notify [readwrite]
> +
> + Indicates whether this characteristic is indicated or not.
> + If GATT Client Characteristic Configuration descriptor
> + is not available for this characteristic, or if the characteristic
> + properties do not allow this, writing to this property is not
> + allowed.
> +
> + boolean Readable [readonly]
> +
> + Indicates wether this characteristic value can be read.
> +
> + boolean WritableNoRsp [readonly]
> +
> + Indicates whether this characteristic value can be written without
> + response.
> +
> + boolean WritableRsp [readonly]
> +
> + Indicates whether this characteristic can be written with response.
> +
> + boolean WritableSigned [readonly]
> +
> + Indicates whether this characteristic can be written with signed
> + authentication method.
> +
> + boolean WritableReliable [readonly]
> +
> + Indicates whether this characteristic can be written with the
> + reliable write procedure.
> +
>
> Characteristic Watcher hierarchy
> ===============================
>
> --------8<-----------
>
> I would appreciate your comments on this.
The additional properties also seem like nice additions, and work well
to provide clear differentiation between the characteristic value and
other metadata.
Thanks for the proposal!
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
next prev parent reply other threads:[~2011-10-27 7:16 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-24 23:06 [PATCH bluez 0/2] Add BT 3.0+HS signalling definitions Peter Krystad
2011-10-24 23:06 ` [PATCH bluez 1/2] Add L2CAP Create/Move Channel definitions Peter Krystad
2011-10-24 23:06 ` [PATCH bluez 2/2] Add A2MP definitions Peter Krystad
2011-10-25 1:43 ` Add BT 3.0+HS signalling definitions Timur Mehrvarz
2011-10-25 7:38 ` GATT Dbus API on BlueZ Ganir, Chen
2011-10-25 12:52 ` Claudio Takahasi
2011-10-25 13:19 ` Ganir, Chen
2011-10-26 0:06 ` Claudio Takahasi
2011-10-26 7:20 ` GATT Dbus API on BlueZ - attirbute-api.txt modifications Ganir, Chen
2011-10-27 7:16 ` Mat Martineau [this message]
2011-10-27 8:22 ` Ganir, Chen
2011-10-27 11:30 ` Mat Martineau
2011-10-27 13:31 ` Luiz Augusto von Dentz
2011-10-27 13:57 ` Anderson Lizardo
2011-10-27 14:02 ` Anderson Lizardo
2011-10-27 14:58 ` Ganir, Chen
2011-10-27 15:13 ` Anderson Lizardo
2011-10-27 15:18 ` Ganir, Chen
2011-10-27 15:35 ` Anderson Lizardo
2011-10-27 15:06 ` Ganir, Chen
2011-10-27 15:29 ` Anderson Lizardo
2011-10-27 15:48 ` Ganir, Chen
2011-10-27 16:29 ` Anderson Lizardo
2011-10-27 16:47 ` Ganir, Chen
2011-10-27 17:32 ` Anderson Lizardo
2011-10-30 6:56 ` Ganir, Chen
2011-10-30 14:23 ` Anderson Lizardo
2011-10-30 15:48 ` Ganir, Chen
2011-10-30 18:02 ` Anderson Lizardo
2011-10-31 6:38 ` Ajay Pillai
2011-10-31 6:57 ` Ganir, Chen
2011-10-31 8:04 ` Ajay Pillai
2011-10-31 10:47 ` Anderson Lizardo
2011-10-31 7:19 ` Ganir, Chen
2011-10-31 11:07 ` Anderson Lizardo
2011-10-31 13:35 ` Ajay Pillai
2011-10-31 14:53 ` Luiz Augusto von Dentz
2011-10-28 16:19 ` Brian Gix
2011-10-28 20:09 ` Anderson Lizardo
2011-10-27 13:32 ` Anderson Lizardo
2011-10-31 17:41 ` Tsai, Mike
2012-01-11 14:25 ` GATT Dbus API on BlueZ Vijaykumar Dadmode
2012-01-11 14:57 ` Claudio Takahasi
2011-10-25 14:41 ` Add BT 3.0+HS signalling definitions Peter Krystad
2011-10-26 0:15 ` Timur Mehrvarz
2011-10-26 7:54 ` Andrei Emeltchenko
2011-10-27 13:39 ` BT 3.0+HS Timur Mehrvarz
2011-10-27 16:46 ` tim.howes
2011-11-03 16:38 ` Timur Mehrvarz
2011-10-26 7:36 ` [PATCH bluez 0/2] Add BT 3.0+HS signalling definitions Andrei Emeltchenko
2011-10-26 17:44 ` Peter Krystad
2011-10-27 8:00 ` 'Andrei Emeltchenko'
2011-10-28 0:23 ` Peter Krystad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1110270003090.30044@mathewm-linux \
--to=mathewm@codeaurora.org \
--cc=bgix@codeaurora.org \
--cc=chen.ganir@ti.com \
--cc=claudio.takahasi@openbossa.org \
--cc=ingas@codeaurora.org \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).