Hi Zoltan, Sakari and Anssi, Thanks for the summary of the DataStore discussion.
Currently Contacts and Messaging API implementation on Android(without DataStore) are reaching their final stages of development. By the end of this week we will be able to submit two Pull Requests, but 80% of the code are related to storage access. So we are eager to know whether the DataStore API proposal will be accepted by W3C or not, and if yes, when will it happen. In another word, whether and when will the SysApps messaging/contact API spec be updated to adopt the DataStore API? Could Zoltan/Anssi provide your insight on this? Based on those info, for our crosswalk project, we have two options regarding this potential change. 1. Continue the implementation according to the current spec, and commit the related PRs to hit M3 milestone. Then update code accordingly when the storage decision is made and the related specs are ready. 2. Hold these PRs until the decision and the specs are finalized. Which option would you prefer? Following are some details of these two APIs for your reference. Current Status (without DataStore): * Contacts API: 1. Save and Update 100% (PR ready) 2. Find and remove 90% 3. Contact event listener 90% * Messaging API 1. SmsManager 90% 2. MmsManager 20% 3. Messaging Manager 80% Impact if switch to DataStore: 1. About 80% of Contacts and Messaging code will be impacted, mostly are Java code. 2. We need to implement DataStore API before continuing Contacts and Messaging. Risk: * W3C Spec of DataStore is not ready. * There is only a wiki page describing DataStore API in Mozilla?¡¥ website (https://wiki.mozilla.org/WebAPI/DataStore). Not sufficient for a spec. * There is more to consider for DataStore API, e.g. synchronization. Regards, Deqing -----Original Message----- From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Kis, Zoltan Sent: Friday, November 15, 2013 4:00 PM To: Gao, Shawn Cc: [email protected] Subject: [Crosswalk-dev] About using DataStore in SysApp Messaging & Contacts API An interim report about the DataStore discussion, since Telefonica asked for more time for making feasibility studies. The current status-quo is based on a proposal from Telefonica and us: we are not going to use DataStore directly, but modify the storage interface so that it is a messaging specific subset of DataStore which can be trivially implemented using DataStore, but also by other means. The current draft is here: https://etherpad.mozilla.org/9MiQ4VWKSO The architectural assumption is there is a system data store for messages, which the app can sync to its cache. Then build indexes to that data, and construct its data model the way it wants, instead of using a central and unified one. Mozilla uses IndexedDB, but it's not mandatory. Read more here: https://wiki.mozilla.org/WebAPI/DataStore This way the Messaging storage interface became simpler, as no search functionality is included. This gives less work for implementers, and more freedom, but also more work for developers. Plus, much more storage space used on the device. Well, this was the choice Mozilla made, and it makes sense to me in its own logic (knowing the performance issues of exposing a native DB through bindings to a web runtime, and after all the "tracker as unified data model" lessons from Maemo/Meego development). Although one could implement the storage API directly (and it would be much faster), I suggest we also implement DataStore, since it is going to be the same story in Contacts API and CallHistory API as well. I suggest holding off storage related development until the decision is made (next week) and the related specifications are updated. Best regards, Zoltan On Tue, Nov 12, 2013 at 3:11 PM, Kis, Zoltan <[email protected]> wrote: > Thank you Shawn. > > One word of warning though: the query API's may change. > Mozilla is pushing for using DataStore API in Messaging. > For that, I proposed to separate the storage interface internally first: > https://github.com/sysapps/messaging/issues/89 > > And also, this older discussion, with a draft spec on how would > Messaging API look when using DataStore: > http://lists.w3.org/Archives/Public/public-sysapps/2013Aug/0077.html > https://etherpad.mozilla.org/un9XkdXeKh > > We will have a discussion about DataStore tomorrow, and I expect some changes. > > So I suggest you don't implement yet any storage and search related > interfaces yet. > > Best regards, > Zoltan > > On Mon, Nov 11, 2013 at 9:19 AM, Gao, Shawn <[email protected]> wrote: >> Intent to Implement System App Messaging API >> >> Summary: This implementation is going to add Messaging >> API(http://www.w3.org/2012/sysapps/messaging/). Let Javascript >> developers have ability to send/receive sms/mms and manage messages on >> Crosswalk. >> Managing features include find by filter, read and delete messages. >> Affected component: /xwalk/runtime >> Related feature: https://crosswalk-project.org/jira/browse/XWALK-53 >> Target Release: M4 >> Implementation details: >> There are 3 parts of implementation. SmsManager, MmsManager, >> MessagingManager. Each of the 3 is divided into 2 side, Java side and >> Javascript side. >> 1. SmsManager. >> 1) Send. Javascript side, when send api is called, create and push >> promise object to waiting list. If get send ok/failure message from >> Java side, found promise object by id and call resolve function. Java >> side, register intent for send ok/failure event and delivery >> ok/failure event. When gets send request from Javascript, call >> Android send sms api. Then receive the ok/failure event, and send these back >> to Javascript side. >> 2) Receive. Javascript side, register receive event handler. Java >> side, register receive event handler by Android Api. When sms comes, >> send message to Javascript side and call receive event handler. >> 2. MmsManager. Similar with SmsManager. >> 3. MessagingManager. Javascript side is similar to SmsManager >> 1) Find. Search sms/mms by ContentResolver. >> 2) Read. Read one sms/mms by ContentResolver. >> 3) Delete. Delete sms/mms by ContentResolver. >> >> >> >> _______________________________________________ >> Crosswalk-dev mailing list >> [email protected] >> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >> _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
