remoteStorage

Comparison with other products


#1

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


#2

actually, “proprietary” goes together with “single instance”, we can merge those columns.

other columns we could add:

  • offline-first client available for the web (the ones supported by remotestorage.js, plus hoodie and firebase)
  • offline-first client available for iOS (Cognito, iCloud, CloudKit)
  • offline-first client available for Android (Googledrive)
  • offline-first client available for Windows 8 (OneDrive)
  • (…)

#3

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.


#4

Pretty sure these 2 are available on iOS (8?) as well.


#5

By the way, here’s a comprehensive overview of Amazon’s current/new app auth and sync services portfolio:

There’s no JavaScript SDK. That’s one of the most important comparison features, which I think we should add as a column.


#6

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.


#7

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.


#8

You could say the same about Angular - why don’t all developers just learn only Ember? :wink: Or why not just extend Ember to include Angular? :wink:

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.


#9

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. :slight_smile: