Hi Thiago,
Thanks for the feedback, we're still struggling the two solutions, let me try to explain the reasons. Requirement analysis： We want to offer native file system api, but no spec to follow up. Idealy, we think it is best to reuse W3C filesystem APIs. Which means we want to extend a new file system type of requestFileSystem(), thus all other JS file api and data structure such as FileEntry, DirectoryEntry can be resued. This is kind of nature for web app developers. At the same time, we should consider the big bulk file operation performance. Currently, there are two solutions are considered: 1. Implement as Xwalk extension(most of you preferred, same with our preference before investigation) 2. Implement inside Chromium/Blink. Investigation results (based on Shawn): In short, inside chromium/blink, FileBlob is the core of file system API, shared memory is already implemented for big file(>128k) operation. But the FileBlob structure is Chromium/Blink internal data structure, not public. This means it is difficult to access from XWalk extension. (If you want to details, please ask Shawn for more details.) If we insist to use XWalk extension way, I’d say above benefit of reuse W3C file API and big file performance consideration is NOT possible. We need reinvent the a new api set for native(maybe same as Caio did for Bracket) and share memory improment. I understand the maintenance effort for patches for Chromium/Blink, but DO we really want to lose this goods because of the maintenance effort? I really doubt. Thanks, Halton. > -----Original Message----- > From: Crosswalk-dev > [mailto:[email protected]] On Behalf Of > Thiago Marcos P. Santos > Sent: Wednesday, January 29, 2014 5:34 PM > To: Gao, Shawn; Oliveira, Caio; [email protected] > Subject: Re: [Crosswalk-dev] The ways to implement native file system api > > On 29-01-2014 08:59, Gao, Shawn wrote: > > Hi, Thiago, > > Blob is living io_thread as private member of FileAPIMessageFilter. If we > are going to reuse blob, our extension thread is hard to access it. So I > suggest if we can modify Blink and Chromium to support native file system. > That's a direct and simple way. Otherwise, if we don't want to reuse blob, > we should recreate whole filesystem, filewriter, filereader for native > filesystem. > > > > Hi Shawn, > > We have two ways of implementing this API: > 1. Doing it inside Blink/Content API. > 2. Implement using XWalk Extensions. > > I don't think there is a compromise where you can mix the two approaches. > Using XWalk Extensions will be easier to maintain as we bump the > Chromium version. > > I would only implement it directly on Blink/Content API with the bless of > the Chromium folks. If you go for 2., the way to start is by sending an > "Intent to Implement" email to blink-dev mailing list. > > Keeping a patch like this in our own tree will be a burden way too heavy to > bear. > > - Thiago > > _______________________________________________ > Crosswalk-dev mailing list > [email protected]<mailto:[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
