For the last two weeks, I've been discussing the beneficial aspects of the iOS walled garden document model. As it turns out, there are quite a few.
That said, let me emphatically state that this model is a bad idea. It forces all stages of your document processing workflow to live in a single application (lest you suffer the pain and agony of tracking multiple document versions). This in turn hurts a developer's ability to deliver functionality incrementally (e.g., a developer who wants to deliver a simple graphics filter has to develop a full graphics editing suite around it).
I regularly use two different text editors (SubEthaEdit and TexShop) when editing LaTeX source, and the LaTeX compiler is a third application that needs to access the files. Sometimes I script certain pieces of functionality (e.g. generating certain tables or graphs). In a desktop processing environment, this is typically trivial. Every bit of data is accessible through a shared filesystem. The lack of a shared filesystem on iOS means that there might be five applications, each with 90% of the features required by your workflow, instead of one set of composable applications that provide all of those features.
This is unacceptable. However, iOS is Apple's sandbox, it's their prerogative to design it how they see fit.
Unfortunately, this is not the only space where one sees the walled garden document model.
Consider Google Docs, Office 365, and iCloud. In theory, they're compatible. They share compatible formats for word processing documents, spreadsheets, and presentations (even if it is the office format). But, like a walled garden, each has its own domain. If you want to edit a presentation in Google Docs, you upload it to Google Drive. If you want to use it with iCloud, you import it into Keynote, and something similar has to happen if you want to use Office 365 or some other online presentation software (e.g., Presvo).
Unlike with the iOS, this does not appear to have been a deliberate decision on the part of the application developers. Every web application has its own mechanism for keeping persistent state, quite simply, because no user would use an application that deletes all your data whenever you quit your browser. They persist state because it's a nice side effect of having to share data between multiple clients/browsers. What they don't do is persist state because they expect another application to be able to start messing with that state.
Let me put that another way. Shared filesystems are (by design) a nice way for applications both to pass data between themselves and to maintain persistent state. The mechanic behind both of these is identical (again, by design): Any application can write data to the filesystem, and any application can read data back out of the filesystem (modulo permissions). In short, a desktop application that needs to store persistent state gets (essentially for free) the ability to automatically exchange data with other applications.
Web applications have no shared filesystem. WebDAV, the one contender that comes to mind, is frequently too unstable or slow for practical use, and made even harder to use by browser security models. Worse still, while desktop application developers can typically assume the presence of some sort of disk drive in the device they're developing for, web application developers can't assume that all of their clients will have a WebDAV server somewhere.
Cloud storage solutions like Dropbox should present a potential solution, but I haven't seen a lot of uptake there either. My guess is that this is a combination of the browser security model issue, and latency issues with realtime updates (If anyone reading this has a better idea, I'd love to hear it).
What this adds up to is that in order to store persistent state, web application developers have had to roll their own application-specific filesystems. They need to persist state, but don't need to make their web application play nice with other web apps (admittedly, services like Google Drive now play nicely with desktop applications).
What we need is a filesystem for the web application world. A system that extends an application's ability to persist state (and/or its ability to replicate and collaboratively edit state with multiple clients), into the ability to collaborate with other applications to form a much more powerful workflow.
The logistics of deploying such a beast (to say nothing of the chicken/egg problem of getting both user and developer buy in) are beyond me at the moment, but it's something that I'd very much like to see happen. Since this post is already getting fairly long, I'll wrap this segment up next week discussing the mechanics of such a filesystem (were it to exist), and how what we learned from iOS in the last two posts can be applied to it.