i was planning to ask Dropbox and GoogleDrive to expose a remotestorage-01 interface, but i want to refrain from that. Given the fact that many of their vital features wouldn’t map on there at all, i think the previous point (making our client lib polyglot) would make more sense. An example is versioning for instance: in Dropbox, you can retrieve a previous version of a specific file. Our spec doesn’t support that. Also, it would be cheaper for everyone in terms of effort if we leave Dropbox and GoogleDrive to expose their own in-house cross-origin APIs. The same goes for tahoe-lafs: while talking to Zooko about how tahoe-lafs could integrate with remoteStorage, our conclusion was that it would be easier for remotestorage.js to add tahoe-lafs support, than for tahoe-lafs to add remoteStorage support. so this would focus a bit away from the spec, and more towards polyglot clients. in a way, this goes back to the idea behind the 2011.10 version http://www.w3.org/community/unhosted/wiki/RemoteStorage-2011.10 which allowed one recommended ‘simple’ API, but also CouchDB, WebDAV, and ‘experimental’ ones like Dropbox, tahoe-lafs, and (at the time) GoogleDocs. but we would just not call these non-recommended APIs part of our spec.
1 Like
we’re adding Dropbox support and GoogleDrive support to remotestorage.js in 0.9