 |
 |
This is interesting. These slides don't give me quite enough info to figure out what's going on (I hate reading slides by themselves!), but I'm curious about this statement: "Without JavaScript coding (even though Google’s API requires JavaScript coding as it is) ". Are you making calls server-side, or are you still making them client-side? As you may recall, one issue I keep beating upon is the desire to call Google's API server-side. While it's technically possible to call it server-side, Google doesn't want you to. I wonder if this is what they're doing there? The problems with that are: 1) It may violate Googles terms of service 2) It may run up against Google traffic-limiting defenses 3) [Google's given reason]: It doesn't allow Google to tailor the results to the end-users location (determined by IP). Including an x-forwarded-for header _may_ get around #2 or #3. Including an x-forwarded-for header should probably be considered a best practice when doing this sort of thing server-side in general, but I'm still nervous about doing this, and wish that Google would just plain say they allow server-side calls. Godmar Back wrote: > Hi, > > here's a pointer to follow up on the earlier discussion on how to > integrate Google books viewability API into closed legacy systems that > allow only limited control regarding what is being output, such as > III's Millennium system. Compared to other solutions, no JavaScript > programming is required, and the integration into the vendor-provided > templates (such as briefcit.html etc.) is reasonably clean, provides > targeted placement, and allows for multiple uses per page. > > Slides (excerpted from Annette Bailey's presentation at IUG 2008): > http://libx.org/gbs/GBSExcerptFromIUGTalk2008.ppt > A demo is currently available here: http://addison.vt.edu:2082/ > > - Godmar > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu