Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [PATCH BlueZ v4 01/18] doc: Add GATT API From: Marcel Holtmann In-Reply-To: Date: Mon, 27 Jan 2014 20:08:28 +0100 Cc: BlueZ development Message-Id: <4CA95C6E-14EA-4D4C-B693-6D7660BF0D2F@holtmann.org> References: <1390398025-28340-1-git-send-email-claudio.takahasi@openbossa.org> <1390845656-29880-1-git-send-email-claudio.takahasi@openbossa.org> <1390845656-29880-2-git-send-email-claudio.takahasi@openbossa.org> To: Claudio Takahasi Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Claudio, >>> This patch proposes an unified GATT API for local and remote services. >>> --- >>> doc/gatt-api.txt | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 145 insertions(+) >>> create mode 100644 doc/gatt-api.txt >>> >>> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt >>> new file mode 100644 >>> index 0000000..2d92f03 >>> --- /dev/null >>> +++ b/doc/gatt-api.txt >>> @@ -0,0 +1,145 @@ >>> +BlueZ D-Bus GATT API description >>> +******************************** >>> + >>> +GATT local and remote services share the same high-level D-Bus API. Local >>> +refers to GATT based service exported by a BlueZ plugin or an external >>> +application. Remote refers to GATT services exported by the peer. >>> + >>> +BlueZ acts as a proxy, translating ATT operations to D-Bus method calls and >>> +Properties (or the opposite). Support for D-Bus Object Manager is mandatory for >>> +external services to allow seamless GATT declarations (Service, Characteristic >>> +and Descriptors) discovery. >>> + >>> +Service hierarchy >>> +================= >>> + >>> +GATT remote and local service representation. Object path for local services >>> +is freely definable. >>> + >>> +External applications implementing local services must register the services >>> +using GattManager1 registration method and must implement the methods and >>> +properties defined in GattService1 interface. >>> + >>> +Service org.bluez >>> +Interface org.bluez.GattService1 [Experimental] >>> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX >>> + >>> +Methods void Release() >>> + >>> + Release this service. At this point, it will not be >>> + used by BlueZ anymore and can be destroyed by the >>> + owner. Method applicable to external GATT services >>> + implementations only (GATT servers). >> >> so this is the part I do not like that much. We should not define an interface that has a method that is valid and used only when this is a GATT server. >> >> What I am thinking right now (and might need to discuss this a bit further), we leave GattService1 without any methods and use it for both GATT client and server. >> >> Then we create some GattServiceAgent1 or GattServiceCollection1 or maybe even GattServer1 that we can register with GattManager1 for the purpose of providing a Release method so that bluetoothd stays in control and can inform applications if it decided to remove a service. >> >> I am even fine with allowing to provide multiple services in a collection/server registration. Thoughts? > > The "Service Agent" approach was suggested in beginning of our > discussion. I don't remember anymore why we decided to change it. > > Unless you think that it is essential, we could implement the > Release() method later. When we start the client implementation we > will have a better understanding of our needs. > Can I remove the Release() and re-send the patch set? as long as this is clearly hidden behind our experimental switch, we can get this started without release method. I want to be cautious since any change would break the GattManager1 interface once we figure out how this should be done best. Regards Marcel