Google Value Proposition
June 8, 2012
Ah yes… I can’t have a “My Field” area of my website without mentioning Google. Google is a one-trick pony and a castle built on clouds. But it is a very good trick, and a very powerful castle. However, have you ever heard of sudden soil liquefaction? That could happen with Google, because most of their revenue comes from fundamentally non-loyal advertisers who will switch their budgets to wherever the eyeballs are. So Google’s mission in life is to ensure that the eyeballs stay there, and that they get some bedrock under that castle—in the form of diversification and significant alternative revenue streams. In other words, become more like Apple. That’s why they’re buying Motorola Mobile. Google, like every other mega-net-co like Amazon and Microsoft, is trying to become more of the necessary and inextricable fabric and infrastructure of the Web and business, much the way DNS is. They’re doing this in the battle over logins, email, social and messaging platforms, office software, and all that happy good stuff that’s becoming cheaper in attempts to lock us in. How do I fit in? So long as Google’s got the eyeballs, they’re the kingmakers, and I tweak things this way and that, trying to affect who becomes and stays king.
Here’s an FAQ about the Google Data API
When Hell freezes over.
The Google Documents List API now looks redundant with the Google Drive API's, with the Drive API being a super-set of the Documents List API, because it is intended to handle a great many more data-types. However, I don't see anything in the Drive API that would obsolete the Data API, because gdata is intended to manipulate the contents of documents directly where they live in the cloud, without need for download or synchronization. It is a subtle difference, but important. GData may become more obscure, because more is going to be accomplished through all-out file synchronization, but still very important for specific types of applications that work on data where it lives in the cloud.
No. Sometimes you have to use both to accomplish what you need. The Documents List API lets you manipulate the name of Google Docs and other files and carry out such actions as copying and deleting entire files. You are working on the file as if in a terminal program or windowing file manager. The Data API lets you manipulate data within an application, like adding data to a document, scheduling a calendar event and the like. Now with Google Drive, there is a choice between using the Google Drive API or the Documents List API for accomplishing very similar file manipulation tasks.
Nope. There are two distinct API controls for Google Spreadsheets: the JavaScript-based one through Google App Scripts (the one you see from inside spreadsheets), and the server-based Google Data API (or gdata for short). The gdata API doesn't provide for spreadsheet formatting. They say it's a philosophical split between the two groups: front-end vs. back-end work, with the presumption that prettying up a spreadsheet shouldn't be in the domain of a "data" API. They're dead-wrong, because without formatting ability, you can't start spreadsheets from scratch because they will look like shit, and you are forever resigned to the world of creating "template" files before-hand that you always have to maintain and copy to get formatting—which creates more surface-area for maintenance and more dependencies. Eventually, the gdata team will come around to realizing formatting belongs there.
There's not much in this for me besides recognition.
{ 0 comments… add one now }