Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

Don't you see the problem with this? By allowing the app, rather than the user or the system, to own the file you wind up with multiple copies.

App A shares data with App B. The user makes some changes and App B saves its new copy. It doesn't send the data back to the originating app. It could, but then the user would have to manually do that and save it in App A again.

This is horrendous! People are confusing the poor UI that we have for files (file pickers) with thinking that files themselves are a bad abstraction.

View on HN

I understand what you're saying, but you need to illustrate an actual problem beyond "technically there's two" that this causes in mobile workflows for typical consumers.

That the current Send-To idiom is limited is not under dispute. That it's worth changing is what's worth discussing.

The 2 copies are not guaranteed to be in sync. If I modify data in App B, App A now has an old copy. I shouldn't have to explain why this is undesirable.

Relax. :) Now we're getting to the crux of the situation.

Let's talk spreadsheets. That's a pretty data-freshness-critical thing, yes? Jennifer gets an e-mail with an Excel attached. She previews the Excel, decides it needs an edit, and taps Send-To -> Numbers (the most common current scenario). A duplicate is created and shipped over to be owned by Numbers.

She makes edits, then clicks Send To -> Email. The correct version goes out. The updated version remains in Numbers. The user assumes that Numbers has the spreadsheet, because that's where she was making changes. The copy in the Mail Attachments archive remains old but it's never invoked a second time and the workflow never takes in stale data.

The only scenario in which Send-To causes problems is in the case of two applications that have equal abilities to process a given filetype AND roughly equal chances of being invoked by a user, and how often is that going to be coming up on a telephone or an tablet?

You could always build a file locking system at the app-level or OS-level or cloud-FS level, but then we're back to Who's Freshest?, the hardest game of all to win.

Apple chose not to play this game and pushed all the filesystem yuckiness out onto a rarely-traveled edge of a regular user's possibility space. It's not ideal, but what is?

Why do there have to be two copies of the file? Could there not be only one copy of the file, with two "begin pointers" that are dated? When a user decides that they no longer need an older version, the older section can be purged. Obviously, this could result in quite large files, and we start wanting to do smarter edits to the contents, but I'm not sure having two distinct copies of the data serve the average user any better than one with two internal copies of the data? Obviously, there are technical challenges, but let's just assume for a minute that years of database and similar use case-driven development have solved many of the basic issues already.

Two copies solves more problems than it wastes space.

What you're describing is concurrent access to a shared resource, which means we now need to start having the following discussions:

- Who's accessing? - Where's the thing they're accessing? - When are they starting? - When are they done? - What happens if they stop talking without saying goodbye? - What happens if changes from User A happen before User B gets a full copy of the starting work object? - What happens if User B deletes everything? Should she be able to? - How do we manage identity? - What happens if the work object is asked to save but is in an incomplete or non-logical state? - What happens if the work object is damaged?

(Now multiply the word 'user' by multiple axes: actual humans, programs, network services, filesystem services)

This is an awful, awful, awful lot of work designed to save the space used by a duplicate 300KB .PPTX file. And frankly, I've only ever seen SubEthaEdit get it right.

Also: the user will never, ever, ever, ever decide to review or delete an old file. That's shit-work, and we are mortal.

A majority of customers aren't even aware that there can be multiple versions of the same work or that the work they're doing can be expressed discretely - they're just doing stuff, and cannot be expected to think about about stuff--.

So in short, let's waste some space and save some hassle. That's what flash chips are for.

This is a very good point. Merging file changes between applications is not a trivial task and usually applications just end up saving their own copy (as you mentioned).

For example, if I share a photo from the Android Gallery app to Instagram, add some trendy filters and share the modified photo in Instagram, I end up with three copies in the filesystem: The original, and two copies made by Instagram to preserve both the original and filtered version.

After all, Instagram doesn't know/care whether the photo came from a camera or from another app, so it always saves a copy of the original.

Also, each time I share the photo to Twitter, Facebook or other cloud service I create another copy with different resolution, (re)compression and even dimensions, which is saved to the service out of my reach.

I guess having multiple unsynced copies of the same information is a problem that won't be solved as long as we want to have the ability to distribute information freely. One interesting development would be better content-based matching of files (e.g. Google similar image search, content-based indexing of photo subjects in Google Drive).

seconded

Reply on news.ycombinator.com