Claudio > -----Original Message----- > From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx] > Sent: Tuesday, October 25, 2011 2:53 PM > To: Ganir, Chen > Cc: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: GATT Dbus API on BlueZ > > Hi Chen Ganir, > > On Tue, Oct 25, 2011 at 4:38 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > > Hi. > > > > Currently, the DBUS API for GATT Client will allow discovering > characteristics and services, connecting to the peer device if > required. However, when the operation is done, the link is dropped (no > more attio registered). The only way to register a global gatt_service- > >attio and keep the connection alive all the time is to register a > characteristic watcher. Is there another way to do it ? I'd like to > keep the link a live (for example, implementing a proximity link loss > profile on top of the DBUS GATT Client) without the need for a watcher. > > > > Thanks, > > Chen Ganir > > > > > > At the moment there isn't another way to keep the link up. GATT > Profiles have different connection requirements, you will need a > dynamic mechanism anyway. The callback registration is the mechanism > to inform the core that connection is required. If you keep the > connection always up it will be necessary a function to get access to > the GAttrib instance and a way to notify that the connection has been > established. > > I tried to remove the association between GAttrib and GIOChannel. The > idea was to create GAttrib even if the link is disconnected, but the > effort doesn't worth. We will have problems with MTU and GATT > abstractions for read long. > > Do have another suggestion to control connections and control the ATT > request/response queue? > > BR, > Claudio Thanks for the reply. However, I did not quite understand your response, nor the relevancy to read long. My basic requirement is to allow a profile to control the connection - meaning that if I implement a proximity or other profile over dbus, I would like to be able to tell it to connect, discover services, discover characteristics, poll from time to time the value of a certain GATT char, or simply idle and wait for disconnection (like proximity does) or notification/indication. When using dbus-send I end up with a disconnected link at the end of the process. Do you think the disconnection results from the termination of the dbus-send application, or is it something else ? Thanks, Chen Ganir. ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
