Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Datastore API (beta)

dropbox.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Datastore API (beta)

#31

Post by natch »

timdorr wrote: post #11
mmahemoff wrote: post #8

Something I don't get about Dropbox API: Why can't I just throw URLs at it? If a user wants to save , 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.)

You're describing the Saver Drop-In: https://www.dropbox.com/developers/dropins/saver

Can the Saver Drop-In be used with arbitrary third-party URLs? To me this is what was being described, so if not, then no, it's not describing the Saver Drop-In.

Re: Datastore API (beta)

#32

Post by icebraining »

peterkelly wrote: post #25

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…

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

Re: Datastore API (beta)

#33

Post by davidjgraph »

peterkelly wrote: post #25

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…

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/

Re: Datastore API (beta)

#34

Post by JosephRedfern »

mmahemoff wrote: post #8

Something I don't get about Dropbox API: Why can't I just throw URLs at it? If a user wants to save , 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.)

How would system-wide caching work unless the HTTP server dropbox requested the file from sent a checksum of the file being requested? Just because something has the same URL doesn't mean that it's the same file at the other end (http://wordpress.org/latest.tar.gz for instance)

Re: Datastore API (beta)

#36

Post by peterkelly »

icebraining wrote: post #32
peterkelly wrote: post #25

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…

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

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.

Re: Datastore API (beta)

#37

Post by peterkelly »

davidjgraph wrote: post #33
peterkelly wrote: post #25

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…

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 fa…

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.

Re: Datastore API (beta)

#39

Post by DTE »

icebraining wrote: post #32
peterkelly wrote: post #25

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…

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

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

Re: Datastore API (beta)

#40

Post by davidjgraph »

peterkelly wrote: post #37
davidjgraph wrote: post #33

Earlier quoted context omitted.

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 fa…

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.

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.

Post reply on HN