I'm still irritated with Google Reader story. How long is this one going to be around, year, two? I think Google should start pledging a number of years they will support a service, why should the developer be taking most of the risk?
Don't build a business or product that relies on a proprietary API with no service agreement. APIs with no service agreement are okay if they're well-documented and have multiple providers, proprietary APIs are fine if they have a service agreement. Something like this should not be used as the base for your product, it should only be used as a means to provide an extra feature to an existing service. This is allows you to integrate your real-time web application with drive, it's not a foundation to build your real-time service on top of.
Just because google shut down reader doesn't mean that this applies to their APIs more than any other company's. If you build something that relies on an API that can disappear at any time, you have nobody to blame but yourself.
That's actually a good point. Giving people a "minimum guaranteed time" for APIs and services would give a lot more confidence to people looking to build on them, and also keep data portability at top of mind when building on those services.
Some of Google's API do have this, it'll be in their terms of service under "Deprecation Policy". The deprecation policy is a promise that if the service is going to be discontinued you'll have at least X notice.
The examples I can think of off hand are all Google App Engine related but I wouldn't be surprised if some of the Drive APIs have the same thing.
I'm pretty sure they already know the minimum time they want to keep a certain service afloat. Would they really lose much if they publicly announced a date, after which they would reevaluate a service? I think I'm giving Google free PR advice here... damn you Google!
Here we have what looks like a cool, well documented, API to a powerful service supported by a major company and instead of talking about the cool things we could build with it we seem to be indulging in that most deplorable and pointless of past times - the fan boy cat fight.
This is still called "Hacker" news correct?
FYI the translate API is paid - not retired. The rates are very low and free for limited use. Furthermore CalDAV was one of the worst things I have ever had the displeasure to work with - why are we mourning that ?
Now - can we please talk about something worthwhile like ... Oh! ... the OP /rant
Yeah, it's been 6 whole days! Some people really dwell in the past, don't they? I don't see what the big deal is, especially since Google has already given us something way better, which will replace RSS, Twitter, Facebook, and probably email – in a couple of months everyone will be using Google+ and we'll have forgotten all about Reader.
You talk like its a person - it's a damned service ...
Plus my point was that the demise of Reader had nothing to do with the OP, and that its continued discussion in any post containing the letter G was pathetic, detracting from more interesting conversations we could and should be having - like the one about the possibilities of the new Drive API...
I'm tired of the railroading and the assumption that a for-profit organization has some sacred duty to think about anything more than its bottom-line. That Google thinks beyond its bottom line quit often (Glass, Cars etc...) is to its credit - IMO that it does not do so all the time (Wave, Buzz, Video, Reader etc...) is NOT to its discredit.
They plan on charging people for Drive space, so I see the underlying storage as a Dropbox competitor while the convenience of online collaboration tools and document editing meant to push them out, as it is heavily integrated into other Google services.
The self-fulfilling prophecy[1] is a powerful phenomenon. If Google pledges 3 years support, then I will assume it's going to be killed in 3 years and not even bother trying to build a business on it, even though Google only means that as a minimum. If everybody assumes the same, then the API probably will end up dead in 3 years, because nobody is using it. On the other hand, since Google makes no such pledge, I don't feel like this API has an expiration date. Instead, I look at this as Google's latest product, and I might want to be the first to integrate it into my service, because it could be the next big thing. If enough people think that way, then the API will thrive and stick around. Sure, the API could still disappear, but any startup built on it has a greater chance of dying before the API does.
Google's problem right now is that it has pissed off a vocal minority with the Google Reader shutdown, so any announcement is being met with pessimism and mistrust.
No expiration date is just an evil omission. The risk is of obsolescence is there, whether they state the date or not. Making the risk visible to everyone makes the situation clearer for everyone. All that is needed is a table like http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173
Isn't this the risk any time you build on top of someone's API? At least with Google Drive they have a clear revenue story - compare that to say, Twitter.
Yes I'm not a huge fan of Google, what is your point? They are a for profit corporation, so I'm not sure why I'm obliged to like them.
There has been a lot of Google news the last week, and loads of submissions on HN, so I've made quite a few posts on them. That is hardly comparable to having an account for a year or more but only ever posting in stories about a single corporation to defend that corporation.
I don't know why you linked my submissions, only 4 out of the last 30 of them, going back ~560 days were about Google or Google products.
I don't think anyone is saying that you're obligated to like them. The problem they have is probably with your tone, which suggests that Google is obligated to literally never, ever shut down any product they experiment with.
Both of the api are still available. Translate is the same as before but you must pay for it, google web search has been replaced by google custom search and you must pay for it.
But Google has retired quite a few APIs before. Search API, CalDAV, Google Base Data API, Social Graph API, Translate API, and the list goes on.
Google Docs looks like it has a healthy future, but they very easily could decide they don't want the API out there. Particularly with Google's newfound lack of fear of pissing people off.
Well, there is a fundamental difference between some of these retired API in the past and this one:
in the first case the developer is the user adopting the API, and enhancing his own service with it, without the end user noticing it.
With this new API the end users of the product will be people with google accounts which will be able to seamlessly interact with 3rd party products. This greatly benefits the company as a platform, which seems to be the recent focus (which led to unpopular unfortunate choices as dropping "leaf" products).
It's ok to criticize that choice etc, but that's another topic.
I guess that if you want to build an application which leverages on the google's ecosystem, it's a reasonably safe bet it won't be dropped soon, as google has a immediate return from it (unlike translate API for instance).
Nothing lasts forever and I obviously can't guarantee you anything on Google's behalf, but the difference here being APIs and products launched before Larry Page became CEO and those launching after.
That's not really a great difference though. Couple years time and Larry will be doing other things or working on some newer, more interesting problems. I don't see this API surviving more than a couple years considering the speed that Google Docs/Drive continues to change.
The difference is Drive is a flagship "L-team" product, so it's pretty much on equal standing to Google+ in terms of priority. When Larry Page took the helm he created 7 core focus areas + accompanying SVP's (A nice summary: http://tech.fortune.cnn.com/2013/01/03/google-larry-page/).
Last weeks reshuffle which had the Maps and Commerce units absorbed into the Knowledge and Ads units respectively and Pichai taking over Android brings it down to 5 focus areas:
SVP of Knowledge/Search — Alan Eustace, SVP of Identity/Social — Vic Gundotra, SVP of Advertising and Commerce — Susan Wojcicki, SVP of YouTube/Video — Salar Kamangar, SVP of Android, Chrome and Google Apps — Sundar Pichai
The key distinction between Drive and Reader is that Drive is pretty much the embodiment of Google Apps itself, whereas Reader was an orphaned product which didn't have a home in any of these 5 post-Page areas.
Any change to this API in a couple of years will be the introduction of v2.
Drive is now a pillar of Google's services, not just Apps but Google Now and search rely on data stored in it, and with many competing storage services around any differentiating feature is worth having.
I'm not the OP, but I don't think he was necessarily talking about the Google Reader API (rather just the service). If you're getting hung up on documented/undocumented APIs, pick any one of the deprecated examples from this list (http://googlecode.blogspot.com/2011/05/spring-cleaning-for-s...) and substitute it in for Google Reader.
I was talking about the service, it doesn't really matter for the user if it's in a form of API or not. I do "PAY" google with my wasted brainpower when I see ads they serve (adblock possibility aside). Seriously though, there's nothing free but it works both ways, it's only fair and long lasting when both sides treat the arrangement as a contract.
How is that arrangement a contract? If you came to Starbucks every morning and bought a cup of coffee, would you consider that to be creating some kind of contract with them?
Assuming I trust Google with all the data and all my users have Google Drive, this looks like a super easy way to make documents created in a web app editable in real time by multiple users.
I'm curious about the details though, which would be ironed out with some more detailed playground examples. Does the API handle merging of the update events on the client side, or do I have to do all that work myself from the stream of insert/removal events? Can I handle them myself if I want? Assuming I want to extend the UI of these updatable strings, so that people can see other people's cursors and such, what would I need to do? Is the client-side library extendable so it can update my UI without hammering my customizations (cursor position, formatting, embedded data transformed into HTML)? How will that scale once the document grows to a considerable size (will I be able to update only changed portions of the DOM created by a large document without doing my own complex diffing logic on the client side)?
For example, build me a basic rich text editor in this that mimicks some of the features of Docs, and show me how much extra code that takes. This code sample by itself doesn't make me confident that the above features would be simple: https://github.com/googledrive/realtime-playground/blob/mast...
It's precisely those richer features of the Google Docs experience that people crave when they say they want to add "realtime collaboration" to an app, not just .val()'ing form fields to the latest known value from the server. Right now this looks like it has the features of a backbone.js + Couch adapter (e.g., http://janmonschke.com/projects/backbone-couchdb.html) except Google sits on all my data.
This is pretty awesome. It seems like the models are similar to the operational transformation models that they've been using in Wave/Docs (with the batched client operation submissions). It's definitely much more advanced than what Meteor does, which is just last-writer-wins.
Still, I'm a bit wary that they're offering this as a API, rather than a framework. I don't know if I would build an application completely on top of an external API...
Given that it seems to require building everything on the three collaborative primitives, and that much of Wave and the ideas behind operation transformations are open, it seems plausible that someone could build an open source implementation of the server component that the JavaScript library could then hook into.
This is slightly off-topic, but since everybody's commenting about it anyway: Was Google Reader (and Posterous, to a lesser extent) the tipping point for awareness and activism surrounding the shutdown of free services? This could be a big thing in 2013.
The tipping point for me was Twitter's increasingly hostile approach to third party devs.
I've been racking my brain trying to think of the first service that I used regularly that was shut down. Pownce maybe? (anyone else remember that?).
I'm currently hunting for a replacement for Gmail that is self-hosted, or at least a solution where the cost of switching providers is low (i.e. I could shift my email to a new host without changing my email address or losing my message history). I'll probably end up using some sort of IMAP provider. There are a lot of features I'd stand to lose though. Conversation view is hugely useful, and Gmail's spam filter is just unbeatable.
both twitter and in some part google have recently acted very hostile to the notion of the open web. (Although referring to corporations as a singular entity irks me somewhat)
The API seems to require users (and not just developers) to have to authorize the app :-(
This kinda limits you to Google Docs style apps, as opposed to other crazy ideas I might have. I would also like to have an option to pay so that I can keep our users data private.
They should fix Google drive before launching an api... I don't understand why google didn't fix it yet. It's a big issue, bigger than the google reader thing... People use Google drive for their business (and some pay, like me), not google reader. WTF Google ! We are waiting so long !
Sorry yes I assumed everybody knows because I know many people having problem around me... The famous unsyncable file, everybody I know including me have this issue. For some people Google drive use 100% of the cpu until it crashes, always, whatever they try. I got often disconnected for absolutly no reason.
Well, I have collegueS that just can't make it work on their computers (recent iMac and macBook).
And When I search on google, i find easily many people having the same problems, even today.
I love Google product, but currently Google Drive is huge fail for me, I hope they fix it soon. They didn't update their app since a long time I think...
I think that seems to be a common problem with Google. It could be only 1% of people are having the trouble you are having. But that could mean 10,000 people(not sure about real numbers) but at 1% it isn't on Google's priority list. :(
You should report the bug (or upvote it, if that's the kind of bug tracker Gdrive uses). And convince everyone you know to, as well. The best way to get a bug addressed is to file it through official channels.
This is really a great API for developers and I can see a lot of different applications. Let's not let google reader's closing negate all the tools google provides for free.
Google closing reader was probably something to do with the French un-digital papers that wanted the interwebs going to their website-o-pages to read content there.
