Chrome OS has no real file manager, and it’s not really clear that it has anything resembling a normal file system. If it does, the user doesn’t see it. This is a pretty radical departure from the last few decades of standard industry practice.
One might be tempted to think Chrome OS can only get away with this because it provides very limited functionality. But some reflection will reveal that this is not quite true. It is quite possible to build complex ecosystems of software and data without the existence of files and file management. This is how the cloud works, for the most part. Even in web-based app that provide something that looks a little like a file management interface, like Google Docs, you’re not really manipulating real files, most of the time. You’re probably manipulating database entries; you don’t know and don’t care, because instead of interacting directly with the data store, everything is filtered through context-specific code that implements the necessary functionality.
And the desktop might be headed this way as well.
Consider. A decade ago, when early adopters took photos with their newfangled digital cameras, they generally thought of those photos as files and managed them in a file manager.
Today, they’re far more likely to manage them using an app like iPhoto, which understands a lot more about photos than a generic file manager does, and hides all the details of the actual file storage from the user. And iPhoto specifically does something really interesting here: it provides a system-level API for accessing the contents of your photo library, that other Apple and third-party apps can use. So even when opening a photo in another app, the user still doesn’t have to worry about actual files.
The key distinction is that instead of the user working with “image files” — chunks of data that are largely opaque to the operating system — the user works with “photos”, which the system now understands as a primitive type. That is, a photo is no longer a type of file, it’s just a type of data that the system knows how to work with in addition to files.
This is sort of how the cloud works. For the most part, discrete files don’t exist in the cloud. Look at something like Flickr. It’s very much built along the same lines as OS X’s photo library support — there’s an application roughly equivalent to iPhoto (the main Flickr web site) for accessing and manipulating photos, and there’s an API that provides access to other applications that want to access that same data and functionality: blogs that want to embed Flickr images, desktop apps that want to upload them, web-based image editing software, etc.
There is still a key difference between this and what iPhoto is doing on the desktop, however. The Flickr application and the data it acts as a gateway for are both globally addressable. You can pull up the application with nothing more than a URL and a browser. Most specific data elements have their own unique addresses. Data can therefore be passed around “by reference” rather than just “by value” (that is, with nothing but a URL), and specific functionality of the Flickr web site/app can be invoked remotely.
This is what makes the cloud a cloud, rather than, to abuse the metaphor a bit, a bunch of isolated individual water droplets.
It’s easy to see how cloud/desktop convergence could play out here. Bring global addressability to the desktop. Instead of local applications working with files, they’d work with data that is accessed through standardized high-level type-specific APIs. Code running on your local machine would expose your locally stored photo library (for instance) through an API much like the one Flickr uses to expose access to the photos it stores. This API would be based on open web technologies (XML-RPC, etc.) and would be the standard mechanism through which both local and remote applications accessed that data and any functionality exposed by the process that implemented the API (maybe it can rotate photos, crop them, perform image recognition, whatever).
Instead of having a world of structured API-accessible data in the cloud, and discrete applications and files on the desktop, this brings cloud-style data management onto the desktop, allowing both the elimination of traditional files and file systems (except possibly as internal implementation details) and seamless integration between local and remote data and functionality. Your local machine would be fully integrated into the cloud, rather than merely being a terminal for accessing the cloud.
It’s hard to avoid the conclusion that we’ll end up here, sooner or later.
