 |
 |
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