Re: Simple API proposal for writing file in local file system


2013/10/19 Jonas Sicking <>

> On Fri, Oct 18, 2013 at 11:11 AM, Jeremie Patonnier
> <> wrote:
> > My proposal does not suggest to do something different than what is
> > currently possible (except the silent saving). Just to ease the life of
> Web
> > dev by avoiding them to work around their usual problem:
> >
> >    - Instantiate a full DOM object and listen for its events just to
> pick a
> >    file sucks
> >    - Being unable to silently save a file granted by the user to be
> savable
> >    sucks.
> I agree that the current API for bringing up a filepicker is pretty
> bad. It's something that has come up many times but the appetite for
> creating a new API that has the same feature set as an existing API
> has been about the same as it usually is: very low.

Yes I understand.
However, the current API to open a file is very poor and could be seriously
improved to let web developers provide a better user experience to their

For example, currently there is no way to know if a user abort the
operation to open a file (by canceling the opening window) and therefor no
clean way to provide some feedback at the application level (for example by
letting the user to choose a file that was already open... or just say to
him that the application won't work without a proper file.)

> The ability to open a file with read/write access is definitely an
> interesting one and one that would be an excellent addition to the web
> platform. However the trickiest piece is not the exact API. It's how
> to design the user experience such that users understand that they are
> giving more than readonly access to a file.

Yes I totally agree with you on that. I'll come back with some proposal
about this latter this week.

> I understand that the FileWriter or FileSaver APIs from Google could
> be part of a solution that did this, but as far as I can tell neither
> is enough on their own, at least as defined in [1].

Actually the current draft is quite out of sync with the current Chrome
implementation. In a web dev point of view and to solve the current problem
raised in this thread, the file writer spec [1] is currently no better than
the one suggest by Mozilla [2] (Technically speaking, it's another story).
Both are just a wrapper around a virtual file system but does not allow to
actually write in the real file system (but I need to dig further into
Chrome implementation).

> If the Google API or implementation allowed opening files in
> read/write mode, can you show an example snippet of code that triggers
> this?

Okay, I'm working on this to see what is exactly possible in the current
state of implementation. I'll also fiddle with the Microsoft API in order
to see what's possible with it.


Web :
Twitter : @JeremiePat <>

Received on Monday, 21 October 2013 08:34:22 UTC