Re: [RFC 7/7] Update Management API documentation

Hi Johan,

On Thu, Jun 16, 2011 at 10:08 AM, Johan Hedberg [off-list ref] wrote:

quoted

I would like to bring attention to a thread I attempted to start some
time ago, named "D-Bus GATT API for external/proprietary profiles". If
anyone is really willing to implement external profiles over D-Bus,
please voice your points that would support this. Note that this
attempt never happened before, AFAIK all bluez supported profiles are
implemented internally on bluez source code, usually as plugins.

Not all profiles. There's e.g. the OBEX profiles provided by obexd. The
main reason for that separation is that practically everything handled
by obexd is user data which doesn't belong in a system level daemon like
bluetoothd. The same system-user separation could be a reason for other
profiles to exist in separate processes. Then there's also partial
splits like that for HFP where audio is handled by an audio subsystem
like PulseAudio and signaling by a cellular subsystem like oFono.

Thanks for the clarification. I completely forgot about these cases
(also I don't actually know how obexd integrates with bluetoothd,
blame on me). But looks like the decision to whether to implement a
profile fully inside or outside (partially or not) bluez is per
profile, right? I think GATT profiles are so diverse that we would
have to make the decision on a profile basis. In this case, it helps
each profile having its own D-Bus API and plugin.

Proximity, for instance, is so attached to the connection state (and
depending on RSSI and TX power) that it would be an example of one
profile that is best implemented next to BlueZ.

Future GATT profiles which might need to read a lot of user
information might need a split from bluetoothd process.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil