Imagine this: All the major players in the space (Dropbox, Box, Google Drive, Skydrive, Sugarsync etc.) as well as app developers got together and came up with a standard way of doing this that makes it possible to use a single protocol & API for all online storage providers. I see this being a good thing for everyone - users can choose whatever service they want, app developers can easily provide their customers with a ton of options, and storage providers don't have to explicitly produce their own SDK or court developers to do integration with their service. We did have WebDAV, but that doesn't seem to be widely adopted by any of the major players.
I've been facing this problem myself with my own app; it's a lot of work to support all the major services and this is really just plumbing stuff that everyone would rather be taken care of so they can focus on the more important stuff. I had a meeting with Box recently where I proposed the idea of an open source framework for iOS which would provide a common native API that abstracts over all the different REST APIs used by different storage providers. The people I spoke to seemed quite open to the idea and agreed that it would be useful. I don't think a library like this would necessary be considered a bad thing by any of the major players, as it evens out the playing field and makes it easy to support different services.
If you're interested in taking part and/or using such an API in your iOS app, I'd love to hear your thoughts on the matter. I have some code already (which I haven't released yet) and am looking to clean up the API a bit, but I think it would be useful to a lot of developers.
Anything but fairly trivial apps quickly run into problems with application data (how relevant), file patching, file intents (Google have this),
Google have, IMO, the most advanced solution in the space, so you could argue have the most the lose from standardising. But in fairness, some of their stuff (I'm thinking the real-time collaboration part of the Drive API) is so complex, there's no way you'd ever see it in a common standard.
That said, it'd be really nice to see a common API over the lower stuff.
I believe filepicker.io have something along these lines as well, but haven't had a chance yet to look into the details of it.
Obligatory presentation by Bruce Schneier on the online feudalism: http://www.infoq.com/presentations/cloud-security
What happened to FTP anyway? I know there were a number of issues with it (security, working through NAT, lack of a standard directory listing format etc); but these were all problems that people managed to solve in different ways.
It just goes to show how far how our industry is willing to embrace change for the sake of change (with the results sometimes being inferior) every time a new buzzord appears. I reckon a modernised version of FTP would do the job pretty well.
What I'm mainly concerned with at the moment is building something that recognises a widely-adopted protocol is going to be very difficult politically to achieve (and get implemented), but a library which abstracts over the different protocols would relieve most of the pain.
Every software company attempts to expand until it
offers a cloud-based platform API. Those companies
which cannot do so are replaced by ones which do.
If a user wants to save <thing at URL>, I have to pull it to my server and push it into Dropbox. Dropbox could just have grabbed it directly and in many cases, won't even have to thanks, to system-wide caching.
(This is based on the last time I looked at the API; maybe this is supported now, but I don't think so.)
Try boxcryptor - works with more than just Dropbox.
https://www.dropbox.com/developers/datastore/tutorial/ios#re...
Seems like a very significant limitation. No mechanism for storing hierarchical data structures. For example, this is certainly not capable of storing arbitrary JSON data as a Record.
Parse has an offline cache, that only caches query results and not actual objects. So any local saves/updates are not reflected until you get network access again, unless you manually implement your own cache.
Firebase is better at handling realtime changes, but is lacking in any realtime capabilities at the moment. Also Firebase's mobile authentication SDK still isn't released yet so no way to handle users yet either.
[1]: https://www.dropbox.com/developers/datastore/tutorial/androi...
Also by 2-way sync I mean 2-way cache sync. Firebase is actually really good with 2-way sync, but without cache/offline (yet) it's kind of a dealbreaker for me.
It looks like Dropbox may be using Operational Transformation [0] to merge changes to lists:
Lists are special field values. They contain an ordered list of other values, though not other lists. Lists can be manipulated via four list operations: put (i.e. replace), move, insert, and delete. These list operations allow Dropbox to handle merging changes to the structure of the list automatically. [1]
iCloud, on the other hand, uses the coarser, state-centric approach of whole document versioning. [2] (Edit: okay, key-value property versioning is also available.)
But iCloud lets the app control conflict resolution, while the Dropbox Datastore API only lets you choose from a predefined set of conflict resolution strategies. [3]
Which approach provides greater value to the app developer? Has Dropbox realized here that developers are just not comfortable implementing a custom merge strategy for entire documents, and not having to worry about this is worth some loss of control?
[0] http://en.wikipedia.org/wiki/Operational_transformation
[1] https://www.dropbox.com/developers/datastore/tutorial/ios#re...
[2] http://developer.apple.com/library/ios/#documentation/DataMa...
[3] https://www.dropbox.com/developers/datastore/tutorial/ios#co...
If you have a Firebase app open and you lose network connectivity, the app still continues to work fine and any modifications you make will be synced back to Firebase when you regain connectivity.
What we don't (quite yet) do is handle the case where you make changes, kill the app (without regaining network connectivity), restart the app, and then get network connectivity, but that's coming soon.
As for other differences, Dropbox Datastore seems to be tightly tied to Dropbox, so the end user for your app must have a Dropbox account (and if they want to collaborate with other users, those users must also have Dropbox accounts, etc.). So it's really for building apps on top of Dropbox.
Firebase and Parse are just generic backends, with no ties to other services, so your end users don't need anything to use your app.
As for differentiating Parse and Firebase, Firebase deals with data in real-time, pushing updates to apps as soon as data changes. Parse is a traditional request/response model, where your app has to explicitly "refresh" to get new data.
Limiting Dropbox functionality on iOS would be met my swift user opposition, something that doesn't guarantee recurring sales.
I'd rather they work on an end-to-end encryption system with a focus on ease of use.
Any Dropbox employees read HN?