Hi Deqing, There’s no spec for Data Store API yet. And according to Mozilla, it will take months to have the first draft out. Given this data, I suggest we do not block the experimental implementations on Data Store APIs availability.
If we care about this functionality, you should try implement the current Messaging and Contacts specs now, document any issues, and channel the feedback to the working group thought our participants (me, Sakari, Zoltan, Kenneth). While doing this, we must acknowledge and understand these specs are unstable, and the implementation would likely need to be revised, and plan accordingly. Your implementation feedback is important input to the standards process as we iterate the specs. Together, we can influence the direction of the specifications. For example, we can have a say whether the Data Store experiment makes sense from the implementation point of view. Thanks, -Anssi On 20 Nov 2013, at 13:11, Kis, Zoltan <[email protected]> wrote: > Dear All, > > Just a short answer, I am in a workshop, will return later with more > detailed answer. > > I am in intense and controversial discussion with Mozilla and > Telefonica about storage methods, even as of now. > > We already know the search methods will be removed / demoted from the > spec. I am sorry about the work done already. IMO we can keep the code > since it's useful and is a super-set of the standard API, but almost > surely it will not be part of the official spec. > > On how do we do the DataStore related functionality (mainly sync), is > still discussed. > DataStore is not even part of the SysApps charter yet, but Mozilla is > pushing it by all means. > > This will take some time. I will move on and propose publishing a > version of the Messaging and Contacts spec without the search and > filtering functionality for reference, while the discussions last. > > Since we don't have an editor in Contacts spec (Chris has left), do we > want to fill that gap? Sakari? Anssi? Or is it enough that I follow it > up as just a regular SysApps member? > > Best regards, > Zoltan > > > On Wed, Nov 20, 2013 at 7:40 AM, Huang, Deqing <[email protected]> wrote: >> 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
