One of the challenges that the ChromeOS presents the user is that of how to change their computer use profile to fit the ‘webOS’ paradigm that it necessitates. True, most people live ‘within the web’ at least some of the time–the social media butterflies know how to do this well–but relatively few people live so much on the web that the absence of a standard disk-based file structure won’t make itself known very quickly.
Part of the reason for this is that the web, despite the profusion of ‘sharing’ services, still maintains a model of uploading and downloading, using the netizen’s computer as a hub for activities. That’s the way that the web was implemented in the first place, with the personal computer being viewed as the target for all significant file transfers.
Unfortunately, this model also requires significant disk space–if you wish to, for instance, publish one of your photos from one service to another, the usual procedure (assuming you’re not working on a computer where the photo is already stored) is to download from one and upload to the other, using your disk as a sort of stopping point. This requires that you have sufficient space on disk (and sufficient access to the file system) to store the file at least temporarily–something which the ChromeOS has been reluctant to support.
An alternate method is to transload the photo: to take the URI of your photo and instruct another service to get hold of the photo on your behalf and to publish it on their server. Imageshack, as an example, offers this. Outside of photos, though, there are few transload services–some exist for, for instance, transloading Rapidshare files, but they are relatively few and usually require paid services.
Google’s ideal model is to grant permissions to users to view or edit the documents as appropriate; documents can be shared and copied within their cloud–but the documents remain entirely within their cloud. There are no easy ways to grant permissions to single outside agencies to copy or transload documents; if I want to, for instance, move a document over to the Microsoft cloud, I’m forced to use the PC-hub model. Granted, half the point of the operations of these clouds is for the operating agencies (Google, Amazon, Microsoft, et al.) to have as much data within their ‘domain’ as possible, and it would be counter to their best interests to allow free data flow between them. However, users who have (for instance) been stung by DRM in the past will note that, no matter the promise of any particular cloud, no matter how fault tolerant or resilient it might be, it’s not something that’s directly under their control: their data is being cared for by another party, and the user is forced to trust them to some extent.
Ideally, best practices would dictate having data available from multiple sources, just in case; the storage available locally on the CR-48 is sufficient to allow user-mediated transloading to, for instance, the Microsoft Office web apps (for which a link is available in the Chrome web store) for now. As time goes on, services to provide transloading across other services are bound to appear; these early-adopter frustrations will lessen over time as the fixes become available.
Living without a disk is not the easiest resolution to make in this new year, but for some people, it may be worth a try–especially if they wish to make the migration to a cloud-based habitat.