From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <3D02B219753AD44CBDDDE484323B1774112D143D@SHSMSX104.ccr.corp.intel.com> References: <1405986034-29122-1-git-send-email-armansito@chromium.org> <20140722085507.GA29664@t440s.lan> <3D02B219753AD44CBDDDE484323B1774112D121F@SHSMSX104.ccr.corp.intel.com> <3D02B219753AD44CBDDDE484323B1774112D143D@SHSMSX104.ccr.corp.intel.com> Date: Thu, 24 Jul 2014 10:58:48 +0300 Message-ID: Subject: Re: [RFC v1 0/1] doc/gatt-api: New API properties and methods for the GATT D-Bus API. From: Luiz Augusto von Dentz To: "Gu, Chao Jie" Cc: Marcel Holtmann , Arman Uguray , BlueZ development , Johan Hedberg Content-Type: multipart/alternative; boundary=001a11337ec8a9db9a04feebd37d List-ID: --001a11337ec8a9db9a04feebd37d Content-Type: text/plain; charset=UTF-8 Hi Arman, On Thu, Jul 24, 2014 at 7:11 AM, Gu, Chao Jie wrote: > Hi Arman, > > > Explain to me how, using only the InterfacesAdded signal, an > > application can know that all characteristic objects under a service > > hierarchy have been added? The only way is if the external application > > already knows about service it's interacting with, which is not the > > case if you're building a generic application API on top of > > bluetoothd. Without what I'm proposing, you can't build a generic GATT > > application API without requiring cumbersome event handling for each > > service, characteristic, and descriptor object as they get added and > > have only partial access to these objects in the handlers as the > > objects are getting processed. This might be fine for low-level > > applications that interact with D-Bus directly, but for higher level > > app developers this is a real issue that we want to handle properly > > and make their lives easier. > Im just wondering why we did not use variant type instead of array of bytes for value, imo it seems a better fit since it can be extended with different types in host byte order. > You are right, we work on Tizen Bluetooth-frwk which is low-level > service/application in system . Bluetooth-frwk can take a role to handle > D-Bus informaiton and give defined API to application such as > characteristic discovery method, so we refer to different level application > indeed. > From your aspect, I understood that you consider that high level app > developer how to get characteristic array directly from bluetoothd. . > > Tizen has to follow BlueZ design, you can offer a C binding for it exposing the exact same (or a subset) of the D-Bus API, anything other than that will cause a maintenance burden in your end. -- Luiz Augusto von Dentz --001a11337ec8a9db9a04feebd37d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Arman,


On Thu, Jul 24, 2014 at 7:11 AM, Gu, Chao Jie <chao.jie.g= u@intel.com> wrote:
Hi Arman,

> Explain to me how, using only the InterfacesAdded signal, an
> application can know that all characteristic objects under a service > hierarchy have been added? The only way is if the external application=
> already knows about service it's interacting with, which is not th= e
> case if you're building a generic application API on top of
> bluetoothd. Without what I'm proposing, you can't build a gene= ric GATT
> application API without requiring cumbersome event handling for each > service, characteristic, and descriptor object as they get added and > have only partial access to these objects in the handlers as the
> objects are getting processed. This might be fine for low-level
> applications that interact with D-Bus directly, but for higher level > app developers this is a real issue that we want to handle properly > and make their lives easier.
=C2=A0
Im just wondering why we did not use variant type instead of array of by= tes for value, imo it seems a better fit since it can be extended with diff= erent types in host byte order.
=C2=A0
You are right, we work on Tizen Bluetooth-frwk which is low-level ser= vice/application in system . Bluetooth-frwk can take a role to handle D-Bus= informaiton and give defined API to application such as characteristic dis= covery method, so we refer to different level application indeed.
>>From your aspect, I understood that you consider that high level app develo= per how to get characteristic array directly from bluetoothd. .


Tizen has to follow BlueZ design, you ca= n offer a C binding for it exposing the exact same (or a subset) of the D-B= us API, anything other than that will cause a maintenance burden in your en= d.=C2=A0

--
Luiz Augusto von Dentz
--001a11337ec8a9db9a04feebd37d--