在 2017年04月19日 17:28, Anne van Kesteren 写道:
On Wed, Apr 19, 2017 at 11:08 AM, duanyao <duan...@ustc.edu> wrote:
This is really not intended. I just don't quite understand some of those
points. For example,
Is "the web being fundamentally linked to HTTP" just the current status of
the industry, or
the inherent philosiphy of the web? If the latter, some explanation or
document would be very
I suspect it's actually a little higher-level than HTTP, with that
indeed being the current state, but the web is about the exchange of
data between computers and definitely sits at a higher level of
abstraction than the particulars of the Linux or Windows file system.
It's hard to define concretely I think, but being platform-independent
and having data addressable from anywhere are important principles.
It's quite helpful, thanks.
If "addressable from anywhere" is a hard requirement then file: url is
doomed with the web,
and further discussion would be unnecessary. Though
platform-independency could be achieved technically.
Well, I meant accessing local files from local files without user
actions (e.g. XHR/fetch), mainly used
Doesn't file: protocol also abstract away much of the file system? What
parts make it a bad abstraction?
You mentioned casing and unicode normalization.
File URLs (it's not a protocol really) are still fundamentally tied to
the file system, including how it's hierarchical and such. And then
indeed there's all the legacy implications of file URLs.
I'm not particularly eager to write access myself. Maybe we can seperately
discuss read and write cases.
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.
to load a web app's own assets.