RE: flush() | was Re: FileSystem API Comments
Hi Arun,
We believe that the flush property should be specified when getting the file
handle as in option 1. One benefit of this is that it will enable the buffer of
both reads and writes for the same handle. On the other hand, if we specify it
on every write operation (as in option 2) we could run into inconsistencies
when invoking the write method with and without the flag.
Based on our interpretation of option 1, it seems as though the flush()
function would not be available. This is how we perceived its usage would look
like:
navigator.getFileSystem().then(function(root) {
return root.openWrite("path/to/file.txt", {autoFlushing: true});
}).then(function(fileHandle) {
fileHandle.write(blob); // data is written to the system cache and is
flushed to disk without delay
});
Thank you,
Ali
From: Arun Ranganathan [mailto:a...@mozilla.com]
Sent: Friday, October 31, 2014 11:19 AM
To: Ali Alabbas
Cc: Web Applications Working Group WG
Subject: flush() | was Re: FileSystem API Comments
Greetings Ali!
I've been thinking about the discussion of flush(), and would like to see if I
can make my previous statement a bit more nuanced. It turns out that flush()
(in the vein of fsync/sync) is pretty useful, and after discussion with a few
folks within Mozilla, I realize that it isn't as simple as tacking it on to the
"write-family" of Promises - as you point out, it is a potentially expensive
operation.
Something like a flush feature might help the following use cases:
1. Creating a database technology on top of the filesystem technology. This
might include IndexedDB, but also WebSQL (as a hypothetical example). Most
transactional operations like this need the ability to do something like flush.
2. Then, there's the use case of compiling C++ codebases to JS. Well-known
examples of this are games, leveraging asm.js. In this genre of use case,
sometimes a large database is brought over (e.g. sqlite). It could be memory
backed, but it is a definite bonus if it could be filesystem backed. Something
like flush helps make that a possibility.
Now the question is how to do this in a WebAPI, allowing for the power along
with the mitigations that a web app might need, notably for performance? A few
ideas below:
On Oct 21, 2014, at 4:36 PM, Ali Alabbas wrote:
* flush()
- This is costly functionality to expose and is likely to be overused by
callers. It would be beneficial to automatically flush changes to disk by
allowing the default file write behavior by the OS. For example, on Windows, we
would leave it up to the filesystem cache to determine the best time to flush
to disk. This is non-deterministic from the app's point of view, but the only
time it is a potential problem is when there's a hard power-off. Most apps
should not be concerned with this; only apps that have very high data
reliability requirements would need the granular control of flushing to disk.
In those cases a developer should use IndexedDB. So we should consider
obscuring this functionality since it's not a common requirement and has a
performance impact if it's widely used.
I agree with the idea of obscuring the functionality a bit, especially given
that it might not be necessary for a large class of operations. A few ways to
do that:
1. Add this to a dictionary option when coining the FileHandleWritable from the
Directory (e.g. add it to something like the OpeWriteOptions:
http://w3c.github.io/filesystem-api/Overview.html#widl-Directory-openWrite-Promise-FileHandleWritable--DOMString-File-path-OpenWriteOptions-options).
This way, the developer has the ability to "coin" a "more expensive" promise,
if that particular set of write operations needs this feature.
2. Add this to the set of options on the FileHandleWritable.
This could be by dictionary, again. Or, it could be a boolean on the
FileHandleWritable's write(). This latter might not be specific enough. Like
other implementations, ours is not going to buffer anything, but rely on the
underlying operating system's buffer for writes and reads.
3. Stick with the idea of a method, like flush(). In this case, we might have
to caveat the use of this, since the possibility of inexperienced developer
misuse is high :-) It might help to see if we can determine some boundaries on
this.
Any feedback on some of these options would be valuable. I am thinking of 1.
and 2.
- A*
Re: New approach to activities/intents
On Tue, 4 Nov 2014, at 03:42, Anne van Kesteren wrote: > A couple of us at Mozilla have been trying to figure out how to revive > activities/intents for the web. Both work relatively well in closed > environments such as Firefox OS and Android, but seem harder to deploy > in a generic way on the web. > > What we've been looking at instead is solving a smaller use case. A > Sharing API to start and then hopefully reuse the building blocks for > other features that need to be liberated. > > https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very > minimal Sharing API could look like. > > Our thinking is that something like the overlay browsing context could > be reused to make e.g. or "save as" extensible going > forward. > > However, admittedly it still doesn't really click. It feels a bit too > much like e.g. the various search extensions browsers offer. Too much > work for little return. Furthermore, freeing the web somehow from > closely knitted silos seems like a worthwhile goal, but is often > counter to what those silos are interested in. So it might be that > we're still not quite there yet, thoughts appreciated. My understanding of the document is that a website can register itself as a share endpoint but can't try to programmatically starts a share action; instead, the user will use the browser UI to do so. Is that correct? I assume also that the UA would show a UI requesting the user whether they want to accept foo.com to be added as a share endpoint, right? Wouldn't be worth experimenting first with a list of predefined share endpoints (that you anyway might want to have) and see if the feature is actually something that users are looking for? Furthermore, wouldn't that make sense to have a similar mechanism than Open Search and have a way for a website to advertise its share endpoint(s)? Maybe the Manifest could be a good use for that. Generally speaking, I see a lot of common aspects between Open Search and this proposal. -- Mounir
[Bug 27261] New: [Custom]: definition construction algorithm step 6 makes no sense
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27261 Bug ID: 27261 Summary: [Custom]: definition construction algorithm step 6 makes no sense Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: bzbar...@mit.edu QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Step 6 is: 6. If PROTOTYPE's interface inherits from SVGElement, set NAMESPACE to SVG Namespace But PROTOTYPE is, afaict, just some random object, so it doesn't make sense to talk about its "interface". The spec needs to define what the actual check to be performed here is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27260] New: [Custom]: Need to define global/Realm handling for registerElement
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27260 Bug ID: 27260 Summary: [Custom]: Need to define global/Realm handling for registerElement Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: bzbar...@mit.edu QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Created attachment 1535 --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1535&action=edit Testcase Consider this testcase: var f = document.registerElement.call(frames[0].document, "x-foo"); Per the spec, this should "let PROTOTYPE be the result of invoking Object.create with HTMLElement's interface prototype object as only argument". But it doesn't say _which_ "HTMLElement's interface prototype object" should be used. Then the spec says to run the "custom element constructor generation algorithm", but this algorithm assumes an ambient global, which the spec doesn't define. In practice, the Chrome and Firefox implementations differ, as the attached testcase shows. The output in Chrome: ctor instanceof iframe Function: false ctor instanceof parent Function: true proto comes from iframe: false proto comes from parent: true The output in Firefox: ctor instanceof iframe Function: true ctor instanceof parent Function: false proto comes from iframe: true proto comes from parent: false I believe the Firefox behavior is more correct here, by the way, since we're supposed to be using the registry of the iframe document, so should use its prototypes and constructors. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27259] New: [Custom]: custom element constructor generation algorithm doesn't do anything with REGISTRY
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27259 Bug ID: 27259 Summary: [Custom]: custom element constructor generation algorithm doesn't do anything with REGISTRY Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: bzbar...@mit.edu QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 It's grabbed at step 3, but never used. Should it be used? Perhaps something involving adding DEFINITION to REGISTRY? -- You are receiving this mail because: You are on the CC list for the bug.
