I was thinking of both covers and 'digitized text availability'.

But the reason I want to in fact do both server side is because of the
architecture I am trying to create here. We have a variety of systems
that should use both these services. We, like many people, are trying to
move to a more 'service oriented' type architecture, where I have one
component of software that does all of these lookups, and then provides
the resulting data in a uniform format via a local web service for all
my other user-facing interfaces to use. Of course, doing that requires a
server-side lookup. But that overall architecture is much preferable
(from a code efficiency and maintenance perspective)  than having to
include customized AJAX for a variety of services (Google Scholar being
just one; Scopus is another content-provider that frustratingly provides
an Javascript-only API) in a variety of ever-changing user-facing
interfaces. DRY and all.

Jonathan

Tim Spalding wrote:
>>  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.
>>
>
> Aren't we still talking about covers? I see *no* reason to go
> server-side on that. Browser-side gets you what you want—covers from
> Google—without the risk they'll shut you down over overuse.
>
> T
>
>

--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu