Hi, 2011/6/17 Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx>: > Hi Ajay, > > On Fri, Jun 17, 2011 at 5:30 AM, Ajay Pillai <Ajay.Pillai@xxxxxxx> wrote: >> I saw another post from you which seemed to indicate that the GATT DBUS API is not >> meant to be used extensively in systems for implementing profiles or for general App integration. >> (Please correct me if I interpreted wrong) > > The current API implementation (documented in doc/attribute-api.txt) > is not suitable for implementing external profiles, correct. > >> However this information coupled with the tightly coupled nature of the GATT based profiles (as derived from your reply) in BlueZ, is giving >> me an impression that the current development direction in BlueZ can severely curb the freedom of device implementers >> to use the capability of GATT. (not sure if you have discussed this before an concluded, in which case I would be interested to be pointed to another post) > > If these implementers create a BlueZ plugin (in C), they have the full > power of BlueZ GATT stack. Of course, there are the licensing > requirements (I suppose). > >> The way I see it is that the pace of profile spec ratification in the SIG or the pace of development of profiles in BlueZ will probably be too slow >> for the larger community of device manufacturers and Application developers for platforms like Android. >> Besides, the usecases being addressed by the profiles in pipeline would probably be only a fraction of the real potential of GATT, which device manufacturers might want to tap into. > > I agree. But note that currently we lack use cases which justify a > complete GATT API over D-Bus. Feel free to discuss your own use cases, > and propose an API for them. > >> This makes me think that more focus needs to be given to the GATT DBUS API, than what is implied by your earlier post. > > So far we have been focusing on implementing officially adopted > profiles, the current D-Bus API was proposed and implemented at a time > when there were no actual GATT profiles, and so far it has been used > for testing purposes. > >> Do you have plans for making the GATT DBUS API more feature complete? > > At least on the team I work, there are no plans for that. But I wanted > to bring up the discussion anyway, thus my e-mail. > >> Do you see problems in including GATT Servers too in it? >> Are you open to stronger contributions to the GATT DBUS API? ( I am interested to do that) > > I believe we are always open to discussions and contributions :). But > before you begin implementing your proposal, I'd suggest discussing a > draft API first on this list. I'm sure there are other parties > interested on helping on that as well. > >> You posted earlier: >>>To be able to implement a full GATT profile externally (client role), >>>we would need to expose the full GATT (or even ATT) stack over D-Bus. >>>For instance, have methods for each GATT operation, and signals for >>>notifications/indications. >> >>>Is that really what we want? If yes, the Attribute API could have to >>>be severely redesigned. It was not (and currently still not is) >>>intended for that. >> Could you elaborate what is the scope of this redesign? > > If you take a look on doc/attribute-api.txt on BlueZ source, you might > identify some limitations already (assuming you already have some use > cases in mind): > > * There are no way to access custom characteristic descriptors (only > presentation format and user description descriptors are currently > exposed). This is a major limitation if you want to access custom > descriptors. > * No D-Bus API e.g. the server side (only client side) for managing > the Attribute server > * Notifications/indications are registered per server, not per > characteristic (this might be a limitation or not) > * Currently no way to handle cases where new services/characteristics > are added "on the fly" on the server side (i.e. suport for the > "Service Changed" GATT characteristic). Idea: new services or > characteristics could be announced as D-Bus signals. > >> I am interested to know if system integrators can have a mutually exclusive choice between external profiles using BlueZ GATT and BlueZ built-in profiles. > > They could coexist just fine. But for that to work, the attribute > server database needs to be managed by BlueZ, which would allocate > attribute handles as necessary. Also note that UUIDs would need to be > allocated for proprietary profiles (not sure how BT SIG handles that). > > Also consider contributing to the officially adopted profiles (once > they are actually adopted). I really hope we don't see multiple > implementations of an adopted GATT profile. > 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? Regards -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
