557540 - Implement File API: Writer (FileWriter)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Jeff Schiller]

The W3C has reached Working Draft with the File API: Writer spec

http://www.w3.org/TR/file-writer-api/

Firefox needs an implementation of this to match up with its FileReader implementation in 3.6 and to compete with WebKit.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

The draft needs to be reviewed carefully before implementing it.

But sure, this is something to do, perhaps as a GSoC project.

Comment 2

[Jeff Schiller]

Obviously I'm implying careful review and feedback by Mozilla before implementing it... ! :)

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

In particular I'm not a fan of the fact that the FileWriter seems to assume that the user always grants access to indefinitely write to the file. I.e. the file contents can be changed at whim by the web page.

Comment 4

[Jeff Schiller]

I'm just a web developer who wants this feature in my web app.  Please raise concerns/questions here: http://lists.w3.org/Archives/Public/public-device-apis/

Comment 5

[Simon]

Related to this issue probably is the implementation of the File System API [http://www.w3.org/TR/file-system-api/] Hopefully, this will find its way into FF soon!

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

The file system API is a separate thing, and that needs even more careful
review if we decide to implement it.
And I'm going to propose some changes to that API anyway.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Per discussions at the all hands meeting, I will be owning this.

Comment 9

[vb4guy]

Any updates on the status of this?

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We've implemented BlobBuilder (as MozBlobBuilder) which is in Gecko 6.  FileSaver will probably be in Gecko 9.  Not sure yet if/when we're going to implement FileWriter, we've been thinking of a different approach.

Comment 11

[vb4guy]

Kyle,

Thanks for the status update.  I am interested to hear what you guys come up with.

Comment 12

[Ben Francis [:benfrancis]]

I'm working on apps for the front end of B2G (https://wiki.mozilla.org/B2G), including a camera and gallery app. Currently the only method available to store photos offline for apps like these is to base64 encode them in IndexedDB, although support for storing files in IndexedDB is coming (https://bugzilla.mozilla.org/show_bug.cgi?id=661877)

I have come across the use case that a user may take a photo using a web app on their B2G phone, then want to transfer those files to another device (e.g. a desktop PC). The most common way to achieve this is to mount the phone's storage as a USB mass storage device and copy and paste the files using a file manager.

If the "File API: Writer" spec was implemented, would the files be stored in the actual file system of the device, or in a virtual file system backed by SQLite or something else? I'm interested to know whether files written to a device via this API could be accessible as a mounted file system on a USB host.

What I'm describing may come more under another W3C specification, "File API: Directories and System" (http://dev.w3.org/2009/dap/file-system/file-dir-sys.html), which lists a use case for an "Audio/Photo editor" where "Edited files should be accessable by client-side applications [iTunes, Picasa]."?

What's the current position on the implementation of these two APIs?

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Let's file a separate file for accessing USB. I agree that we need some way to do that, but FileWriter wouldn't be enough, we'd need FileSystemAPI as well which is beyond the scope of this bug.

Comment 14

[Marco Castelluccio [:marco]]

FileSystemAPI limits "the scope of access to the local filesystem to a chroot-like, origin-specific sandbox".

Comment 15

[Ben Francis [:benfrancis]]

True, but it also says those sandboxes are "sections of a user's local filesystem" which means that they could be accessible via USB if that file system was mounted as a USB mass storage device.

Because of the same-origin restriction that API wouldn't solve the problem of sharing files between apps (maybe Web Intents can take care of that), but it could solve the problem of getting media on and off the device.

Comment 16

[Marco Castelluccio [:marco]]

(In reply to Ben Francis from comment #15)
> True, but it also says those sandboxes are "sections of a user's local
> filesystem" which means that they could be accessible via USB if that file
> system was mounted as a USB mass storage device.

Yes, this is what I said :D
I think we need something like the FileSystemAPI for B2G, but there isn't any open bug to implement it.
Do we want this API? Should I open a bug about it?

Comment 17

[Ben Francis [:benfrancis]]

Fair enough :)

Do you mean "File API: Directories and System"? There's a bug for that https://bugzilla.mozilla.org/show_bug.cgi?id=704128 but so far the concensus is pretty negative.

Comment 18

[Geoff Flarity]

File Writer WD was updated recently:

http://www.w3.org/TR/file-writer-api/

I'm a web developer doing some pretty innovative stuff with it and I'd hate to have to resort to using Java went users are not using Chrome.  Please, this should be implemented.

Comment 19

[Jonathan Watt [:jwatt]]

Should this be wontfix'ed? The "Low-level file manipulation" section at:

https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/

say's (and explains why) we're going to implement a FileHandle API instead:

https://wiki.mozilla.org/WebAPI/FileHandleAPI

Comment 20

[Jan Varga [:janv]]

yeah, we are not going to implement FileWriter

Comment 21

[Mounir Lamouri (:mounir)]

Lets be clear about it then.