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