They're representations of resources, not files. Some of them are stored as files on the server, but that's purely incidental and irrelevant to the browser; it treats them just the same as it treats the runtime generated representations, such as this HTML we're viewing.
Files are representations of resources as well. Some of these are mapped to data stored on disk blocks, but others aren't. Some file systems are not disk abstractions at all. While I agree that calling HTTP resources "files" is not entirely correct, they're presented in a very file system-like hierarchy, and in most cases I'd say that they are not meaningfully distinct from files in a file system.
I definitely find "The web has NOTHING to do with files" less agreeable than what kyllo is saying.
> You can move them around, read to them, write to them, execute them...
That functionality depends entirely on the file system and the file in question, as much as the operations available on an HTTP resource depends on the verbs that the resource implements and how it implements them.
Also, a file system will typically not execute your files. Nothing stops you from executing an HTTP resource in the same manner. Say,
This HTML we're viewing may be runtime-generated on the server, but it's still saved on my machine as one or more files in a temporary folder and then opened by my browser application, is it not? A web browser is really just a fancy, scriptable file viewer.
And that's for HTTP--not to mention the other major protocol FTP, the name of which is self-explanatory: File Transfer Protocol.
Define "file". Read off from the definition of file whether the WWW is just a set of "files".
If you use the UNIX-like definition of file (to say nothing of the Plan 9 definition), which can include dynamically-generated streams such as /dev/random, then sure, the whole web is a set of files. I assume Plan 9 will even serve web sites out of its "filesystem" with the correct poking.
If you use the DOS-like definition of a static file (ignoring CON and a couple of other special cases), then, no, the web is not merely a set of fancy static files on disk. Many, many, many things never have a rest representation on disk as a simple file, even if one could theoretically be manifested at a point in time for some particular web page.
I sort of feel you're trying to conflate these two distinct definitions, and using the fact that the web is a set of stream-files to assert that the web is nothing but a set of disk-files, but that's equivocation.
This HTML we're viewing may be runtime-generated on the server, but it's still saved on my machine as one or more files in a temporary folder and then opened by my browser application, is it not?
No, it's kept as an in-memory structure. Certain representations are serialized and cached to files, yes, but that's just a optimization to reduce network requests; you can disable it without affecting the browser.
In particular, "grep -r kyllo ~/.cache/mozilla/firefox/" returns zero results, despite having this post open on my browser.
A web browser is really just a fancy, scriptable file viewer.
I disagree; it's an hypertext engine, with renderers for multiple media types. That hypertext can be loaded and/or cached from files, but that's an implementation detail that does not define the application.
And that's for HTTP--not to mention the other major protocol FTP, the name of which is self-explanatory: File Transfer Protocol.
