Hi Arman,


On Thu, Jul 24, 2014 at 7:11 AM, Gu, Chao Jie <chao.jie.gu@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 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