Return-Path: MIME-Version: 1.0 In-Reply-To: References: <4df91d74.0b73650a.190f.17ad@mx.google.com> <1308175855.2196.7.camel@aeonflux> <1308191356.2196.9.camel@aeonflux> <8DCFA6B89B9E70418E47A2348D55495A478165D6@banasiexm01.ASIA.ROOT.PRI> <8DCFA6B89B9E70418E47A2348D55495A4781711C@banasiexm01.ASIA.ROOT.PRI> Date: Fri, 17 Jun 2011 14:53:53 +0200 Message-ID: Subject: Re: GATT and GATT based Profiles architecture - Query From: Santiago Carot To: Anderson Lizardo Cc: Ajay Pillai , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi 2011/6/17 Anderson Lizardo : > Hi, > > On Fri, Jun 17, 2011 at 8:22 AM, Santiago Carot wrote: >> Just a note. If there is a full GATT API and we do BlueZ plugins over >> GATT (wich have their own D-Bus API as usual in BlueZ). The GATT API >> may be in conflict with those APIs exposed by those plugins because >> Applications will be able to use Attribute D-Bus one avoiding those >> APIs exposed by plugins. Do not? > > As long as all APIs use the same stack, there is no issue AFAIK. For > instance, if someone uses the Proximity D-Bus API and another > application does the same operation over the "generic" Attribute API, > both operations will be processed the same way inside the BlueZ GATT > stack (because they use the same functions internally). At least this > is the intended behavior, we don't do much testing like that :) > Yes, sure. the GATT API will allow applications to avoid use API provided for GATT based plugins. In this scenario there will be two ways to doing things. A) Using the plugin API and B)Through the GATT API. ... or in the worst case, an Application may use both. > Regards, > -- > Anderson Lizardo > Instituto Nokia de Tecnologia - INdT > Manaus - Brazil >