On 2017-04-19 11:28, Anne van Kesteren wrote:
I already pointed to https://wicg.github.io/entries-api/ as a way to
get access to a directory of files and <input type=file> as a way to
get access to a sequence of files. Both for read access. I haven't
seen any interest to go beyond that.
Is this the Filesystem & FileWriter API ?
This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge
and Firefox has not picked this up yet (just the Reader part).
(as shown by http://caniuse.com/#search=file )
I avoid prefixed features, and try to use only features that latest
Edge/Chrome/Firefox support so that end users are more likely to not end
up in a situation where their browser do not support a app.
And unless I remember wrong Firefox did support this at some point then
removed it again.
Take for example my soundbank app.
A end user would want to either use a file selector or drag'n'drop to
the app (browser) window to add files to the soundboard.
Let us assume that 30+ sounds are added (I don't even think the
filerequester handles multiselection properly in all browsers today)
Would it be fair to expect the user to have to re-add these each time
they start/open the app? During a week that is a lot of pointless work.
Saving filenames is not practical, and even if it was there would be no
paths.
And storing the sounds in IndexDB or localStorage is out of the question
as that is limited to a total of 5MB or even less in most browsers, 30+
samples easily consumes that.
The ideal here is to make a html soundboard app locally (i.e file://)
then copy it as is to a webserver. Users can either use it from there
(http:// or https:// online and/or offline) or "Save As" the document
and use it locally (file://) for preservation or offline use without
server dependency.
The only way to make this work currently is to make the user hand write
the path (full or relative) to each sound and store that in localStorage
along with volume and fade in/out.
But fade in and out is "faked" by adjusting the <audio> volume as CORS
prevents processing the audio and doing a proper crossfade between
sounds which is possible but locked down due to CORS.
I can understand limitations due to security concerns, but arbitrary
limitations to functionality baffles me.
I do not see much difference between file:// http(s):// besides one
allowing serverside data processing and http headers, but these days
most apps are entirely clientside. A sample editor can be written that
is fully clientside, even including mic recording normalizing, FX, the
server is not involved in any stage except delivering the .html file + a
few lines of headers. The web app itself is identical (i.e.
hash/checksum identical) be it http(s): or file:
The benefit is that "the app is the source code" which is a ideal goal
of open source as anyone can review and copy and modify as they please.
And in theory it could run just as well truly offline/standalone as it
could online without the need for a local webserver or similar.
I'd dare say that thinking of a web app as something hosted only from a
server via http(s) is a antiquated idea.
These days a "web" app can be hosted via anything, want to open a webapp
that is served from a cloud storage like Dropbox? Not a problem.
Well, almost not a problem. a cloud storage probably do not have the
proper CORS header to allow a sample editor to process sound from local
files or files stored on a different cloud service.
And a soundboard or a sample editor is just two examples, a image or
video edit would have similar issues. OR what about a game with mod
support? Being able to drag'n'drop a mod onto a game and then have the
game load it the next time you start the game would be a huge benefit.
But currently this can not be done, the mod would have to be uploaded to
the server the game is served from, even if the game itself does not use
or need any serverside scripting.
Or imagine a medical app that needs to read in CSV data, such a app
could work fully offline/local and load up the data each time it's
started. Storing the data in localstorage/indexDB would be limited to
whatever else is stored as far as size goes, and browsers can just wipe
the local storage/indexDB without warning. At least a local file stored
on d:\docs\ is safe from vanishing.
Even if the app itself is online and served from a server you still
can't have it load a list.CSV from d:\docs\ when starting it for
example. And IndexDB/localStorage is limited to around 5MB total for
that domain. Maybe there is a desire to switch between datasets
list1.csv and list2.csv and list3.csv and before you know it you open
xray.png enhance a area and save that change (in localStorage as you can
save the path and a zoomvalue you have to save the entire image instead)
and suddenly list1.csv get deleted from localStorage for that domain.
And these are limitations to http(s): and not just file:
--
Unless specified otherwise, anything I write publicly is considered
Public Domain (CC0).
Roger Hågensen,
Freelancer, Norway.
