Vic, I appreciate your response. I don't want to waste your time of course, so will just try and respond briefly to a few of the questions below.
Thanks again for the response, and best of luck on your future roadmap, jonathan On Thursday, April 5, 2012 4:19:11 PM UTC-4, Vic Fryzel wrote: > > Hey Jonathan, > > Thank you for the thoughtful post. My comments are below. > > On Wed, Apr 4, 2012 at 6:42 PM, <....> wrote: >> >> Particular details that influenced this decision: >> >> - The API docs (we are using >> https://developers.google.com/google-apps/spreadsheets/) are not >> entirely >> consistent with what is happening. After a few hours of hacking >> around, >> for instance, I discovered that even though the docs encourage >> (require?) >> use of the 3.0 API, some of the things that the documentation >> discusses, >> such as the worksheets feed element, is only available if >> GDocs-Version is >> set to 1.0. Others have mentioned this in various places, sadly >> without >> much resolution that I can see: >> >> - >> http://code.google.com/a/https://developers.google.com/google-apps/documents-list/google.com/p/apps-api-issues/issues/detail?id=2356<http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=2356> >> (Comment 4 especially) >> >> - >> https://groups.google.com/forum/?fromgroups#!searchin/google-spreadsheets-api/worksheets$20feed/google-spreadsheets-api/hrMEWe3oGtU/PgxtMMEYwFYJ >> >> - >> https://groups.google.com/forum/?fromgroups#!searchin/google-spreadsheets-api/worksheets$20feed/google-spreadsheets-api/-foRn23J_TY/Yhusg4za3cQJ >> >> > I've responded to the thread with Alistair on it, which I think is a > legitimate documentation bug. However, the code samples I think are > correct. Which language are you working in? > I'm using Go, so coding to the raw wire APIs and building our own Go client. > > >> - There is a general feeling I get from the docs and the spirit of >> things >> that there is not a truly stable, supportable, bankable API and >> system in >> place yet. I can't say much more than what is already said here: >> >> - >> http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=2516&can=4&q=label%3AAPI-Spreadsheets&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary > > > Please see my update to that bug. Let me tell you though, this API is > stable, and not changing in this version. > > >> - Pivots are important to us. Unless I've overlooked it in the docs, >> there >> is no official support for generating or manipulating pivots. Of >> course we >> might be able to deduce it and hack at it, but I'm not comfortable >> with us >> coding to undocumented APIs. >> > > We don't have support for pivot tables in the API. We will consider > adding support in a future version of the API, as this is a feature request. > > >> - The reliance on Atom APIS, even with the 'alt=json' alternative, is >> unnecessarily complicated and verbose, especially when considering >> realtime needs (below). I remember 2005-6. They were heady times when >> Atom, Rss, any format or protocol with the word "Open" in it, and >> being >> able to claim that your application re-used some other existing >> protocol >> for some new, unintended purpose were all badges of honor. That being >> said, it's not really where we are today as developers, and a more >> straightforward RPC style API would be preferable to us. Indeed, >> many of >> Google's own APIs as described through the discovery mechanism >> (http://code.google.com/apis/discovery/) appear to follow a more RPC >> approach. >> > > Again, we will resolve this in a future version of the API that would be > based on our new API infrastructure and framework. It will give JSON as a > default output format. Wouldn't you agree that this is a feature request? > > I would agree, and certainly give it our +1 :) > - Related to the point above, there do not appear to be efficient ways >> to >> push frequent but small updates. The docs do not discuss this, and >> though >> we could guess at it and experiment with various HTTP-level >> strategies for >> connection re-use, it would seem to make sense to introduce a >> WebSockets >> API for more efficient use of the network. This is admittedly minor >> and >> not as much of a show-stopper for us as the other things above, but >> it's >> worth pointing out as something that I would expect to see addressed >> in a >> network-based API. >> > > This question is not clear to me, and seems a bit vague. The cells feed > is capable of handling "frequent but small updates". What went wrong for > you here? > Nothing went wrong, and I didn't want this point above to cloud the larger discussion. My only real point was that, coupled with the overhead of HTTP and Atom, and given that the API works (as I would expect) over SSL, there is, without something like WebSockets API, an awful lot of TCP overhead involved in an update which might otherwise be sent in a single TCP packet. Again, not a showstopper for us, but worth pointing out. > > >> - When using the GDocs UI to import a tab-separated file of >20K rows, >> the >> import process completed after some time but ultimately truncated >> the data >> set silently. The truncation part was unfortunate, but more alarming >> to me >> was the silence in which it occurred. Although this isn't directly >> related >> to the APIs, it's worth pointing out that it did nevertheless play >> into >> the decision and overall feeling that the system may be either a bit >> immature or that there may be an issue of squashing or failing to >> surface >> errors properly. >> > > Please provide your sample data set so that we can reproduce. What were > the dimensions of the data set? e.g. 20K rows and X columns. Uploading > this file programmatically should be done using the Documents List API: > https://developers.google.com/google-apps/documents-list/ > > >> Ultimately, I set out a goal of publishing a single snapshot of one >> tabular data >> set to an existing sheet that I had set up for us to try things out. >> Ultimately >> after 2.5 days of working with the APIs (using combinations of curl and >> Go), I >> wasn't able to accomplish it definitively. Although I did finally see a >> path to >> success (involving using GData-Version 1.0 for some calls and 3.0 for >> others), I >> was not able to see a final result. >> > > My ultimate feeling was that if I, as a senior engineer, was not able to >> accomplish this task in 2.5 days, and given that this was just the >> starting >> point of our potential integration, I was uncomfortable with the longterm >> prognosis. Ultimately I had to make the judgement call that the >> development >> cost to us and our users would be more than the IT and ops cost of >> setting up a >> competing reporting solution. >> > > For what it's worth, we have a large number of users of the API who are > able to use it. In this email, I have not yet seen a specific bug that > stopped your implementation. Specifically what were you not able to get to > work? Were you able to update a worksheet's cells? > > Apart from lack of pivots API, nothing stopped us, so to speak. My larger point and decision was based on the fact that things were proving too difficult and underspecified for our particular tastes, and that I came away uncomfortable with the amount of time that I felt we would have to invest both in the beginning and in ongoing maintenance, compared to some other options. We'll be eagerly checking the spreadsheets' APIs evolution, and of course are excited to see what you guys continue to do! > Thanks, > -Vic >
