Has the notion of "files" outlived its usefulness?
25hoursaday.com
25hoursaday.com
Yup... another day on HN.
The article posted here is about why we do need files, as is the article this is a reaction to (the filepicker.io post).
"Have files outlived their usefulness? Only if you think reusing data across multiple applications has."
Example: Photos. The file is the photo. However, think of all the things besides that: face tags, text tags, album, ratings, etc. If you've ever tried to import 5GB of photos from iPhoto to Picasa (or vice-versa) you'll understand what I mean.
This is why "stuff in the cloud" is so useful: API support is there from day 1 so that you always know what CAN be exported and how.
They can. It's all just bits. If your files don't and your API does, it is simply because your files don't and your API does, not because files can't and APIs can. Files can have metadata and APIs can be written that treat things as blobs.
There is a distinction, but it's not API vs. file, it's what semantic context you're in. Your MP3 player reads out the ID3 tags, because it's in a music player context. Your backing cloud store (like Dropbox) just sees blobs. Interoperability is less about agreeing on file formats than agreeing on semantic contexts. (Yes, file formats are important but they come later, and most arguments about them are actually arguments about semantic contexts.)
File formats evolve at a glacial pace and suffer from immense historical baggage. No one benefits from pretending that file formats are as accessible, agile or powerful as proper web APIs.
You are everything that is wrong with modern computing. A web API is always inferior to what you can do natively.
To say nothing of the fact that "APIs", Web or otherwise, aren't actually a means of storing data; at least in the context of things like "pictures" and "music", we obviously can never have "turtles all the way down."
I italicized proper there because my real point is that you're simply defining yourself the win with the word "proper" and not comparing like to like. You can win any comparison by accounting for only the good of one proposition and only the bad of the other, but that's not a valid argument. If, for instance, we ask our web API to have some sort of assurance that it'll be there next year... hell, next week... suddenly "proper web API" turns out to resolve to absolutely no concrete noun at all. (How "proper" would you have called the Twitter API last week? You know, back just before Twitter started shutting huge swathes of third party apps out of it?)
But that's just one definition. The truth is you need the right tool for the job.
It is all, in the end, just bits. The bits don't have color [1], and they don't acquire color by being in a web API instead of a file.
I don't believe files are the issue, it's agreeing on the interchange format that is.
Like the resource forks of classic Mac OS files?
A more meaningful question might be to challenge the notion of a hierarchical file system. The web has managed fine without one, so possibly search across a flat collection is a better metaphor. There are numerous others.
There are, however, interesting possibilities that make files less conspicuous, apple are experimenting with this, where there are pipes between apps, I open a photo, send it to snapseed, pipe it on to tumblr. At no point am I confronted with a file save dialog. Obviously it's a file under the covers, but that's just an abstraction. Files themselves are abstractions. There's really no such thing as an mp3 file, it's just a sequence of bytes we can interpret as one.