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

Hi!


2013/10/19 Jonas Sicking <jonas@sicking.cc>

> On Fri, Oct 18, 2013 at 11:11 AM, Jeremie Patonnier
> <jeremie.patonnier@gmail.com> 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
users.

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.

[1] http://dev.w3.org/2009/dap/file-system/file-writer.html
[2] http://w3c.github.io/filesystem-api/Overview.html

-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>