Return-Path: MIME-Version: 1.0 References: <1409295566-13583-1-git-send-email-chao.jie.gu@intel.com> <3D02B219753AD44CBDDDE484323B1774112F697D@SHSMSX104.ccr.corp.intel.com> <3D02B219753AD44CBDDDE484323B1774112F6F57@SHSMSX104.ccr.corp.intel.com> From: Arman Uguray Date: Tue, 02 Sep 2014 20:25:11 +0000 Message-ID: Subject: Re: [PATCH] gatt api V2 To: "Gu, Chao Jie" , Arman Uguray Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" , Marcel Holtmann Content-Type: multipart/alternative; boundary=089e013a05de9a3c9405021aea39 List-ID: --089e013a05de9a3c9405021aea39 Content-Type: text/plain; charset=UTF-8 Hi Chaojie, The idea is to create a set of tools that can be shared among different platform implementations (desktop, Android, etc.) without direct library dependencies, such as glib. GAttrib is written in a way that directly interacts with GIOChannel whereas the shared stuff use shared/io, which is a simple abstraction that is compatible with GIOChannel and Glib mainloop, as well as BlueZ's own mainloop implementation (monitor/mainloop.c). Beyond removing the dependency issue, the shared code will provide a stand-alone, functioning GATT server/client implementation that is not tied to any daemon code. The idea is that you can instantiate a struct bt_gatt_client, and that will do all the attribute discovery and caching for you. The upper-layer won't need to know about the contents of ATT protocol PDUs or explicit handling of "service changed" indications, etc (similarly, there will be a shared/gatt-server to handle all the GATT server magic). Others can comment more on this, since I've been basically following Marcel's suggestion :) Cheers, Arman --089e013a05de9a3c9405021aea39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chaojie,

The idea is to create a= set of tools that can be shared among different platform implementations (= desktop, Android, etc.) without direct library dependencies, such as glib. = GAttrib is written in a way that directly interacts with GIOChannel whereas= the shared stuff use shared/io, which is a simple abstraction that is comp= atible with GIOChannel and Glib mainloop, as well as BlueZ's own mainlo= op implementation (monitor/mainloop.c).

Beyond removing the dependency issue, the shared= code will provide a stand-alone, functioning GATT server/client implementa= tion that is not tied to any daemon code. The idea is that you can instanti= ate a struct bt_gatt_client, and that will do all the attribute discovery a= nd caching for you. The upper-layer won't need to know about the conten= ts of ATT protocol PDUs or explicit handling of "service changed"= indications, etc (similarly, there will be a shared/gatt-server to handle = all the GATT server magic).

Others can comment more on this, since I've = been basically following Marcel's suggestion :)

Cheers,

Arman

--089e013a05de9a3c9405021aea39--