Re: Request to report the status of the specs

Hi Eduardo,

On Mon, Apr 7, 2014 at 1:31 PM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
>> The use cases we have for backends:
>> - messages coming from device/built-in modem
>> - messages coming from paired Bluetooth devices via MAP (multiple
>> devices should be supported)
>> - contacts coming from device (multiple address books need to be supported)
>> - contacts coming from paired Bluetooth devices via PBAP (multiple
>> devices should be supported)
>> - similarly, local call history
>> - and call history coming from paired Bluetooth devices via PBAP and
>> HFP (multiple devices should be supported).
>
> Some of these use cases, basically the Bluetooth-related ones,
> are out of the current scope of Messaging / Contacts APIs

That is why I raised the issue for including them. We do have
developer pull for these and they are important use cases, both for
runtimes and browsers. The same goes for the SysApps Bluetooth API
scheduled for Phase 2.

Indeed, we could also push including these use cases to Phase 2, but
it would be good to see already now how that would affect the API's.
To my current understanding, it would be fairly low impact (e.g.
paired devices exposed via service id's, with editorial notes about
certain limitations in BT profiles). I am implementing these for
Crosswalk and we can wait with this issue until the implementation(s)
prove this is a viable path, but that doesn't exclude opinion
gathering about the topic.

The other option to fulfill these use cases is to create separate
API's for BT profiles, i.e. separately for generic BT, and then OBEX
profiles. That would duplicate functionality, but at least it would
also separate the concerns.

Either way is about the same effort to implement, the bulk of it being
how to handle the BT side of things.

Best regards,
Zoltan

Received on Monday, 7 April 2014 12:15:48 UTC