From the irc conversation today, should put this on the remotestorage.io website, probably:
Name per-user/per-app single inst./decentr. open source/propr. ======================================================================================
Dropbox per-user single instance proprietary
GoogleDrive per-user single instance proprietary
iCloud per-user single instance proprietary
OneDrive per-user single instance proprietary
remoteStorage per-user decentralized open source
Hoodie per-app* decentralized open source
CloudKit per-app single instance proprietary
Firebase per-app single instance (?) proprietary (?)
Parse per-app single instance proprietary
Cognito per-app single instance proprietary
*) per-user Hoodie is being worked on in a Pull Request
That’s kind of sad, because it means that there’s a mostly CouchDB-dependent API/project instead of a technology-agnostic protocol doing the same thing as we do. No?
Would be much cooler if they implemented remoteStorage somehow as well I think. But I haven’t thought about that in detail at all yet.
I don’t necessarily agree, CouchDB is journal-based sync, remoteStorage is tree-based sync. Also, CouchDB allows complex queries (server-side JavaScript execution with MapReduce), and arbitrary ACLs (you can specify an arbitrary JavaScript function that decides who has access to which file).
I think there’s room for use cases where a per-user hoodie (or maybe even a per-user CouchDB instance) is the best option.
So you want end users to have two different personal storage accounts and developers to learn (!) and integrate different technologies? I think developers will decide on one or the other, no matter what the exact details of the use case, and at the moment it’s rather easy, due to the clear distinction of hosted vs. unhosted tech.
If there are so many use cases for having both, why not extend the remoteStorage spec to accomodate some of them?
A lot of people have been asking for permissions since the protocol exists, so that’s an obvious problem. There’s both a recent new discussion on the mailing list as well as here in the forums.
Complex queries on the other hand shouldn’t be necessary for most unhosted applications in my opinion (depends on how smart you’re using a dumb protocol), and they are the main cause of dependence on one specific backend technology and people not being able to easily implement servers or extend their existing storage solutions to support a common protocol.
You could say the same about Angular - why don’t all developers just learn only Ember? Or why not just extend Ember to include Angular?
I think there is room for multiple per-user data storage protocols for the web. We already have Dropbox, GoogleDrive, remoteStorage, Hoodie will be the fourth one, and I hope tahoe-lafs and ownCloud will follow as well with cross-origin APIs.
Developers don’t learn all of these APIs, they will use a client library like remotestorage.js or hoodie.js. I think it’s up to these client libraries to support multiple backends. Trying to make all storage providers agree on which protocol is the best one is a lot harder than adding code to the client libraries to abstract from the differences between them.
Anyway, this is the current situation, so I think it’s what we should display in our comparison table.
This is where it gets confusing to me. The whole point of a standardized protocol is to eliminate the need for centralized, proprietary protocols and solutions. On the Web we create common standards and protocols for that. We usually only let them compete before they become final specs to see what works best, and then continue with a single one that people agreed upon. (This is an over-simplified view of reality of course, but the general idea.)
Now, as Hoodie is too dependent on a technology to become an open protocol, and the others are all proprietary, we only have remoteStorage as the existing open protocol that could be used by all developers wanting to agree upon a common standard for per-user storage, which can be used and implemented by anyone with any technology they want. And as it’s still very young, we can still accommodate more use cases in the spec, before it gets too difficult to do that. In fact, if we don’t try to do that, we might as well just stop development of it right here, because it would stay an unfinished project forever, lacking support for what developers want of a per-user storage protocol.
I didn’t say we shouldn’t include all solutions in the table – of course we should. I said it’s sad, that we will likely have fragmentation in the user and developer base and a competition of an open protocol with a tech-dependent software project. Let me just be sad and tell everybody why. Maybe more people agree with my preference of open protocols and choose remoteStorage then.