W3C home > Mailing lists > Public > public-sysapps@w3.org > April 2014

Re: Request to report the status of the specs

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Fri, 4 Apr 2014 22:23:20 +0300
Message-ID: <CANrNqUfaG3dSRBfDyq+8YRokeU1uU_8dpHeYRhH7pTHFd=mW2g@mail.gmail.com>
To: Wonsuk Lee <wonsuk73@gmail.com>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>
Hi Wonsuk,

On Fri, Apr 4, 2014 at 9:48 PM, Wonsuk Lee <wonsuk73@gmail.com> wrote:

>> Regarding the Messaging spec, the latest developments with DataStore
>> have not been applied yet - waiting for the DataStore spec to
>> stabilize. This also applies to the Contacts API.
> I think we already had enough time to review for DataStore API. I guess so
> far we didn't have much comments on that from other editors for contacts and
> messaging APIs and other members of the group. So if we have a consensus
> about  there are no outstanding issue and objection within the group, we
> need to apply that to contacts and messaging APIs. What do you think?

Yes, we have discussed the DataStore API extensively.

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

We need to discuss how to solve these use cases with the existing
DataStore spec. It would be good if the spec would contain some
guidelines for implementations regarding the use cases above.

Basically it boils down to support service id's for messaging and call
history, and address book id for contacts. If these are part of the
data, then no issues.

Anyway, I hope that after this F2F we can go and implement DataStore,
then give feedback and run another cycle.

Best regards,
Received on Friday, 4 April 2014 19:23:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:20 UTC