Hi Forrest, > Your patch removes many DBus APIs provided by audio/gateway.c, which > was originally designed to provide a set of DBus functions/signals for > ease of application development. In other words, your patch is too > oFono-specific, and is not a general support for HFP HF unit role in > BlueZ IMO. The DBus interface provided by your patch is not easy to > develop the application because the application developer has to parse > the AT commands by himself. I know that oFono could parse AT commands. That is actually the point :) > But I don't think it a common case for other application developers. > Why not extend audio/gateway.c instead of removing its DBus APIs or > create a new file to support HFP for oFono in blueZ? If we were to extend the current BlueZ API we'd be duplicating all of what oFono has already solved (particularly 3-way calls, multiparty and other advanced features) and force the developers to support yet-another DBus API. This makes no sense and oFono already supports the full HFP protocol along with most of the nasty corner cases. This in fact simplifies things quite a bit... Regards, -Denis -- 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
