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
