[peterkelly]

The biggest problem right now with online file storage services (sorry, I meant "The Cloud") is that while they all do basically the same stuff, there's no standard protocol for accessing them. It's a bit like if every website used a custom protocol instead of HTTP, and web browser vendors had to explicitly collaborate with each web site (or use the website's SDK) in order to be able to retrieve content.

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.

[davidjgraph]

That's exactly the idea of Remote Storage [0]. The problem is here that the lowest common denominator of functionality isn't actually very much.

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.

[0] http://remotestorage.io/

[peterkelly]

Thanks for the link, this does look very interesting.

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.

[davidjgraph]

Filepicker is a API across remote storage as a service and everything goes through the FilePicker servers. There's no library to use directly.

RemoteStorage is specification primarily, but it's very much about their JavaScript library that you use directly to communicate to the remote storage.

[icebraining]

Big players aren't interested in anything that reduces lock-in. Seamless integration is one of the keypoints they have to get you to use their services.

Obligatory presentation by Bruce Schneier on the online feudalism: http://www.infoq.com/presentations/cloud-security

[peterkelly]

I found Box to be the opposite of this. While I obviously can't speak on their behalf, and I was discussing the issue with their developer relations people (not senior executives), they said they didn't see a problem with this idea.

[DTE]

exactly...it is unlikely they would be interested in data storage being treated as the commodity it is.

[nly]

By Jove, you're right! Perhaps what we need is some kind of universal protocol for transferring files. We could call it the 'File Transfer Protocol' or something.

[roc]

As it turns out, the protocol for actually transferring the files is utterly irrelevant compared to the protocol for getting updates, keeping various local stores synchronized, retaining versions, managing conflicts, handling client-side bugs and surprises, etc.

[nly]

It's a good point I suppose. I've never had a need or urge to use a service like Dropbox to keep files in sync though. I prefer just to carry my working copies around, or use Google Docs. Maybe I'm missing out on seamless splendour, I don't know.

[amirmc]

> "Maybe I'm missing out on seamless splendour, I don't know."

I'd say that yes, you are (no snark intended). Dropbox is one of those things that you didn't really know you needed until you've used it for a while. It crept up on me and became indispensable for pretty much every collaborative project I've worked on.

[peterkelly]

Yes, file synchronization is really the hard part from an architecture POV.

From everything I've seen so far, Git appears to provide the best solution. It is rather complex though, and it's a big challenge to build an intuitive user experience on top of this that shields non-technical users from a lot of the complexities.

[peterkelly]

LOL yes ;)

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.

[vidarh]

People didn't "solve" those problems so much as hack their way around them in a wide variety of ways with no standardization, that is the problem. Having to occasionally support customers that need FTP servers, I can tell you that it is a never-ending nightmare of incompatible clients, server settings that must be set differently depending on customer requirements just because of issues with FTP, and firewall problems (on the customers side, though it also creates hassles on our end).

Pretty much anything would be better than FTP.

[nly]

> What happened to FTP anyway?

It's too hard to set-up for casual file sharing (backup, docs, photos etc.), and it's less efficient and scalable than BitTorrent for wide file distribution (piracy).

Perhaps with HTTP 2.0 and IPv6 looming though, we will see some progress on an FTP 2.0 that resolves the issues you mentioned.

[taskstrike]

Hey, this is exactly what NimbusBase (http://nimbusbase.com) wants to do. It's a work in progress to integrate all the services, but we got the major 2 Dropbox and Google Drive.

[brettcvz]

Check out https://www.inkfilepicker.com/