> Google Drive (or Dropbox) support would be an interesting addition to > jclouds. These syncing services provide programmatic access to the > underlying storage, perhaps sufficient to implement the jclouds BlobStore > abstraction.
I think there's some confusion regarding "Google Drive" the Android/iOS/MS Windows application and Google Drive the ReST based data storage service "in the cloud". The former might be labeled as "syncing service", but I think it would be wrong to do so for the latter. > Note that the use cases for syncing services are much different than object > storage (like Google Cloud Storage); the latter tends to scale to greater > number and size of objects, more clients, and support different privilege > mechanisms. So far the documentation I found was surprisingly nebulous and incomprehensible, but my understanding is that Google Cloud Storage is meant for applications to store their data (e.g. maps of a MMORPG or data of a backup _service_) in the application-specific account (billed to the developer of that application), while Google Drive is meant for applications to store data in behalf of the user of that application (e.g. data of a backup _application_) in the user's account (billed to the user). Furthermore (but not relevant here) the data in Google Drive can interact with "WebApps" (important for Google Chrome OS), while there is no such API for Google Cloud Storage. I might be completely wrong of course, I'm certainly not sure (I think Google Marketing has some clean-up to do). > If this interests you, I encourage you to look at the existing Google support > which implements OAuth. This will give you a good head start on any > implementation. Good luck! I certainly will have a look, thank you. ~ Guenther
