 |
 |
This is what I'm worried about too. The API is _intended_ to be used as a client-side javascript. _Technically_ it's of course possible to use it on the server side too. But I am worried that this will run up against un-advertised Google rate limits. I don't think it's a strict hits-per-day, I think it's heuristic software meant to stop exactly what we'd be trying to do, server-side machine-based access. When I emailed Google to ask about this, all I got back was a statement that this is only supported for client side Javascript access. I doubt that users using software with this kind of in-browser Javascript access enabled will run up against any problems with rate limiting. But I think if we try to do it server side, we very well might. Of course, there are many kinds of functions that are difficult or impossible to do solely client side, especially integrating with existing software. So this is a concern. Interestingly, the Ex Libris SFX software demoing integration with Google Books---as far as I can tell makes the API calls server-side! Someone from Ex Libris confirmed to me that they have no special deal or communications with Google. I think they didn't neccesarily realize they might run into Google rate limiting (or even terms of service violation?) issues. It will be interesting to see if they do or not. The architecture of SFX would make it hard to implement Google Books API access as purely client javascript, without losing full integration with SFX on par with other 'services' used by SFX. We will see what happens. Google's _stated_ (to me, in email; I got one reply, but couldn't get them to reply to my followup) reason for only allowing client-side access is that availability may depend on location, and they need to know the end user's location (via IP address) to get accurate availability for that particular end user. This could of course be easily solved if the API URL format allowed the calling client to pass on the end-user's IP address in the URL (&client_ip=x.x.x.x or what have you). But I don't believe the Google Books API currently supports this. I suspect that Google may have other "business model" reasons. Not sure. Jonathan Sebastian Hammer wrote: > Is there any word on a limit to the number of hits per day on the Google > API? I missed it in the docs if it's there, only saw an ominous warning > that you might see the service temporarily disabled if you generated an > 'unusually high number of hits' during development. > > --Seb > > Joe Atzberger wrote: >> Impressive! As luck would have it, I'm working on the question of book >> images in Koha this week... >> --joe atzberger >> >> On Sat, Mar 15, 2008 at 3:14 AM, Godmar Back <[log in to unmask]> wrote: >> >> >>> Hi Tim, >>> >>> I think this proposal suffers from the same shortcoming as >>> LibraryThing's widgets, which is that only one per page is allowed. Aj >>> better way may be to use spans and classes and keep the JavaScript in >>> a library. >>> I've attached the resulting HTML below; see http://libx.org/gbs/ for a >>> demo. >>> >>> - Godmar >>> >>> --- index.html: >>> !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >>> <html> >>> <head> >>> <!cript src="http://libx.org/gbs/gbsclasses.js" >>> type="text/javascript"> </script> >>> <title>Simple Demo for Google Book Classes</title> >>> </head> >>> >>> <body> >>> <span title="ISBN:0743226720" class="gbs-thumbnail"></span> >>> <span title="ISBN:0061234001" class="gbs-thumbnail"></span> >>> <span title="ISBN:1931798230" class="gbs-thumbnail"></span> >>> >>> <span title="ISBN:0596000278" class="gbs-thumbnail"></span> >>> <span title="0439554934" class="gbs-thumbnail"></span> >>> <span title="OCLC:60348769" class="gbs-thumbnail"></span> >>> <span title="LCCN:2004022563" class="gbs-thumbnail"></span> >>> </body> >>> </html> >>> >>> On Sat, Mar 15, 2008 at 2:04 AM, Tim Spalding <[log in to unmask]> >>> wrote: >>> >>>> (Apologies for cross-posting) >>>> >>>> I just posted a simple way to get free book covers into your OPAC. It >>>> uses the new Google Book Search API. >>>> >>>> >>>> >>> http://www.librarything.com/thingology/2008/03/free-covers-for-your-library-from.php >>> >>> >>>> I think Google has as much cover coverage as anyone. The API is free. >>>> Most libraries pay. I'm thinking this is a big deal? >>>> >>>> We'll probably fancy it up a bit as an add-on to our LibraryThing for >>>> Libraries service, but the core idea can be implemented by anyone. >>>> >>>> I look forward to refinements. >>>> >>>> Tim >>>> >>>> -- >>>> Check out my library at >>>> http://www.librarything.com/profile/timspalding >>>> >>>> >> >> > > -- > Sebastian Hammer, Index Data > [log in to unmask] www.indexdata.com > Ph: (603) 209-6853 Fax: (866) 383-4485 > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu