You can, of course, mix the two approachesóget once browser-side, tell
your servers what it said and store that for a while. We do something
like that with Amazon covers. We don't store the covers, but we store
*whether* Amazon has the cover. That way, it can know whether to try
Amazon or not, and whether to fall back on another cover.
On 3/17/08, Jonathan Rochkind <[log in to unmask]> wrote:
> 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.
> > T
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> rochkind (at) jhu.edu
Check out my library at http://www.librarything.com/profile/timspalding