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 -- 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
