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
interfaces. DRY and all.
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.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
rochkind (at) jhu.edu