I also support basing our work of the Mozilla spec Kenneth
On Fri, Mar 14, 2014 at 11:14 AM, Kostiainen, Anssi < anssi.kostiai...@intel.com> wrote: > Hi Shawn, Thiago, All, > > The current standardization status (no change since 31 Jan) of the various > file system APIs may be of interest to you: > > http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0164.html > > In short, there is no consensus yet among browser vendors, and thus no > single API that would be broadly implemented. > > Given the current state, my guidance would be to implement any API that > addresses the requirements you have, and while doing so document the delta > to the spec you reuse, any issues found, so that we can inform the related > standards work. > > Personally I think the "FileSystem API” proposal ( > http://w3c.github.io/filesystem-api/Overview.html) by Mozilla is more > aligned with the current API design best practices (e.g. Promises instead > of callbacks), but AFAICT no-one, not even Mozilla, has shipped it yet. > Also in terms of standards maturity it is an early draft. The showstopper > for you is that it’s a sandboxed file system. That said, web developers > seem to be in favour of the Promises-based API, as we’re getting feedback > such as the following from web developers: > > [[ > > The callback-based approach of the Google proposal let us end up in > callback hell right from the start, so we wrapped the whole API in promises > as best as we could, just to make it usable for our app developers. In that > department, Mozilla’s promises-based proposal might be much cleaner and > easier to work with. > > http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0198.html > > ]] > > By implementing and shipping the feature in Crosswalk regardless of the > shape of the API we are able to gather further feedback from web developers > using the API. > > Thanks, > > -Anssi > > > > On 13 Mar 2014, at 14:56, Thiago Marcos P. Santos <thiago.san...@intel.com> > wrote: > > > LGTM, let me know if I can help on something. > > > > Would be good to have this API on all the platforms we support. > > > > On 03-03-2014 12:11, Gao, Shawn wrote: > >> *Description:* > >> Native file API allows web app developer to read, write and enumerate > >> native file system via JavaScript. From Webapp developer perspective, > >> most of interfaces in W3C _File API: Directories and System_ > >> <http://www.w3.org/TR/file-system-api/> [1] and_File API: Writer_ > >> <http://www.w3.org/TR/file-writer-api/>[2] will be reused. For example, > >> FileEntry, DirectoryEntry, FileWriter, etc. > >> In Chromium technical scope, there are two related file system API: W3C > >> file API[1][2] and _Chrome extension file API_ > >> <http://developer.chrome.com/apps/app_storage>[3]. Neither one can > >> satisfy above requirements: > >> > >> 1. W3C file API is sandbox file system. > >> 2. Chrome extension file API is only available on top of chrome > >> extension, which won’t support on Crosswalk. Secondly, it pops up > >> file chooser dialog each time for security concern. > >> > >> *Affected component:* > >> > >> 1. xwalk/runtime/renderer/ > >> > >> Add code here to handle JavaScript function call to Isolated File System > >> API. Send Isolated File System requests to browser process through IPC. > >> > >> 2. xwalk/runtime/browser/ > >> > >> Handle Isolated File System requests from render process > >> > >> 3. xwalk/experimental/ > >> > >> Inject Isolated File System JavaScript code to render via xwalk > >> extension mechanism. > >> *Related feature: * > >> _https://crosswalk-project.org/jira/browse/XWALK-672_ > >> *Target Release:*** > >> Crosswalk 6 > >> *Implementation details:* > >> The implementaion is build on top of ”Isolated File System”, which is > >> used by Chrome extension file API as well. Blink already have Isolated > >> File System support. So, I can use it to create FileSystem object in > >> Javascript context with out modify upstream Blink code. Then, I am going > >> to follow the Chrome extesnion file API way to implement Crosswalk > >> native file system. > >> File System Design Chart: > >> Limitations: > >> ======== > >> > >> 1. Linux, Tizen and Android will be supportted. Windows and MacOS are > >> not condidered. > >> 2. Sync file API is not included in this feature. > >> > >> Security consideration: > >> ================= > >> > >> 1. For Linux and Tizen: reply on Crosswalk extension security machanism. > >> 2. For Andoid: WRITE_EXTERNAL_STORAGE and MOUNT_UNMOUNT_FILESYSTEMS > >> need to be declared in the activity manifest. > >> > >> IDL: > >> === > >> /[Supplemental, NoInterfaceObject]/ > >> /interface FileSystem {/ > >> /void //_requestNativeFileSystem_/ > >> <http://www.w3.org/TR/file-system-api/>/(DOMString path, > >> //_FileSystemCallback_/ > >> <http://www.w3.org/TR/file-system-api/>/successCallback, optional > >> //_ErrorCallback_/ <http://www.w3.org/TR/file-system-api/ > >/errorCallback);/ > >> /};/ > >> Description: > >> Requests a native filesystem in which to store application data.If > >> successful, this function must give access to a native files ystem, as > >> defined above. > >> Paramters: > >> > +----------------+--------------------+---------+--------+-----------------------------------+ > >> |Parameter | Type |Nullable |Optional| > >> Description | > >> > +----------------+--------------------+---------+--------+-----------------------------------+ > >> |path | DOMString | no | no |The real path > >> on native system | > >> > +----------------+--------------------+---------+--------+-----------------------------------+ > >> |successCallback | FileSystemCallback | no | no |The callback > >> that is called when | > >> | | | | |user agent > >> provides a file system | > >> > +----------------+--------------------+---------+--------+-----------------------------------+ > >> |errorCallback | ErrorCallback | no | yes |A callback > >> that is called when | > >> | | | | |errors > >> happend, or when the reqeust| > >> | | | | |to obtain the > >> filesystem is denied | > >> > +----------------+--------------------+---------+--------+-----------------------------------+ > >> > >> Return Type: void > >> More background: > >> ============== > >> There are two options were discussed before, neither are accepted with > >> reasons. > >> > >> 1. Improve file API in Blink to support out-of-sandbox file access. > >> Abondoneded because of maintainence concern. > >> 2. Implement a new file API that expose the C file API interface. > >> Abondoneded because incompatible with W3C file interfaces. > >> > >> *References:* > >> */[1] /**/_http://www.w3.org/TR/file-system-api/_/* > >> */[2]/**//**/_http://www.w3.org/TR/file-writer-api/_/* > >> */[3] /**/_http://developer.chrome.com/apps/app_storage_/* > >> Thanks, > >> -Shawn > > > > _______________________________________________ > > Crosswalk-dev mailing list > > Crosswalk-dev@lists.crosswalk-project.org > > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
