Hacker News Reader

Comment by abstractbill | Hacker News Reader

Files are an abstraction that allows multiple applications to operate on the same objects (photos, videos, etc).

The argument here seems to be that the cost of the abstraction (user confusion) isn't worth the benefit, and that we should go back to only allowing one application to access each kind of object.

I have to disagree. The abstraction might not be perfect, but it does enable something pretty damn useful.

View on HN

No, no, that's not what I'm saying at all.

You have a database in the iPhone called Photos & Videos. You store all photos and videos in there.

Then you can open any number of apps -- photoshop, Camera, Photo Viewer, Mail, etc -- and act on those files. Any changes you make will be centrally reflected in all the other apps, since there's only one copy of the file.

In the primary app for any particular database, say Photos, you can create albums and organizational structures based specifically on that type of data: Albums for photos, for example.

I wish you had said this in your article. This is a pretty good solution for the problem you described.

I've been thinking that a standard cloud-app-filesystem-service that any app could register to use would solve the problems with no-user-filesystem .

Wait, now I am confused. I thought your article was about the death of files, but you've just mentioned files twice in relation to photos on the iPhone, albeit files within a database.

Ok, so that's less restrictive than you made it sound in your article. I'm not sure you want to kill files or filesystems at all. In fact, all you want is a filesystem that enforces the restriction that files of a given type should always live under a directory that holds only files of that type.

Ok, reasonably interesting. I'm not completely sold, but I can see it has a lot of advantages - it might work! One open question for me: Where do things like zip archives live? They don't seem to have a logical place to be.

You also seem to want to rename "filesystem" to "database". I'm not sure why. A filesystem is already a (specialized) database.

If you are catering to non-technical users, I would hope they wouldn't have to deal with zip files. Compression could be treated more like metadata, rather than a type of file (i.e. the filesystem transparently compresses them based on usage patterns or preferences).

But in general, I think there are two types of files: files needed by a user and files needed by programs. A good solution would make it so that the non-technical user doesn't need to know that the latter kind exists.

okay, how do you associate photos, videos, emails, driving directions, and a formal invitation booklet that you received as a PDF with that cruise in the South Pacific several years ago to see the total eclipse. If all those electronic artifacts aren't "files" and the collection of them is not a "folder" (<rant>it's a directory damn you heathens !!!</rant>) that documents your trip how exactly do you organize your stuff ? Do you tag each and every object with the word "South Pacific Eclipse Cruise?" in the application that you use to access it? How do you find all the pieces associated with that trip? How do you find out if you do have a copy of that invitation booklet? I'm wondering how to practically move past "files" and "folders" ? (<balmer-rant>Directories, Directories, Directories .... </balmer-rant>)

You need an app called "project file manager", which creates tags to the "files", and puts them in a "folder". Easy.

And we go round again, sooner or later someone will complain that the tags and folders are too difficult to deal with.

For something like that, how about an app like this?

http://www.popplet.com/

For what you're talking about, typical people would rather have something like Microsoft Courier than a hierarchical directory. Popplet is Courier for multitouch.

Reply on news.ycombinator.com