Hi Tim,
I think this proposal suffers from the same shortcoming as
LibraryThing's widgets, which is that only one per page is allowed. A
better way may be to use spans and classes and keep the JavaScript in
a library.
I've attached the resulting HTML below; see http://libx.org/gbs/ for a demo.
-
Oh yes, you're right. My point was to illustrate the point with a
small piece of code, not to write the perfect implementation. Multiple
covers is one improvement you'd want.
I think the main problem is getting the identifiers off of the OPAC
and putting them back in the page where they're useful.
Impressive! As luck would have it, I'm working on the question of book
images in Koha this week...
--joe atzberger
On Sat, Mar 15, 2008 at 3:14 AM, Godmar Back <[EMAIL PROTECTED]> wrote:
> Hi Tim,
>
> I think this proposal suffers from the same shortcoming as
> LibraryThing's widgets, which is t
Is there any word on a limit to the number of hits per day on the Google
API? I missed it in the docs if it's there, only saw an ominous warning
that you might see the service temporarily disabled if you generated an
'unusually high number of hits' during development.
--Seb
Joe Atzberger wrote:
Thanks Tim.
I noticed the service and It thought your script was small and just does all it
needs to do.
Pasted it into our OPAC. But I only take the covers from Google, when Amazon
does not have it.
I like the ones from amazon better :)
For those interested: http://library.wur.nl/desktop/catalog
As i wrote earlier, I have implemented a link using the Google API in
our library catalog.
It worked . for a while :)
What we notice now is, that Google responds with an error message. It
thinks that it has detected spyware or some virus.
i see the same effect now when I click on the examples
FWIW, realize that this is client-side mashup. Google will see
individual requests from individual IP addresses from everybody
viewing your page. For each IP address from which it sees requests
it'll decide whether to block or not. It'll block if it thinks you're
harvesting their data.
Wageningen
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Godmar Back
Sent: Monday, March 17, 2008 9:09 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
FWIW, realize that this is client-side mashup. Google will see
individual req
> 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—cover
Although I completely agree that server-side queryability is something
we should ask from Google, I'd like to follow up on:
On Mon, Mar 17, 2008 at 11:06 AM, Jonathan Rochkind <[EMAIL PROTECTED]> wrote:
> The
> architecture of SFX would make it hard to implement Google Books API
> access as pure
On Mon, Mar 17, 2008 at 11:13 AM, Tim Spalding <[EMAIL PROTECTED]> 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?
Original message
>Date: Mon, 17 Mar 2008 11:13:58 -0400
>From: Tim Spalding <[EMAIL PROTECTED]>
>Subject: Re: [CODE4LIB] Free covers from Google
>To: CODE4LIB@LISTSERV.ND.EDU
>
>> limits. I don't think it's a strict hits-per-day, I think it's he
This is what I'm worried about too.
The API is _intended_ to be used as a client-side javascript.
_Technically_ it's of course possible to use it on the server side too.
But I am worried that this will run up against un-advertised Google rate
limits. I don't think it's a strict hits-per-day, I th
Well, the SFX architecture has a feature called "display logic" that
let's you on the server side determine how the menu will display based
on what services are available. This is more obviously relevant to
"digitized text availability" from Google Books than just cover images.
You might want to s
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
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 'se
On Mon, Mar 17, 2008 at 10:41 AM, Jonathan Rochkind <[EMAIL PROTECTED]> wrote:
> Well, the SFX architecture has a feature called "display logic" that
> let's you on the server side determine how the menu will display based
> on what services are available. This is more obviously relevant to
> "d
Of course, all these things _can_ be done with only client-side
javascript API. To my perspective, it is quite a bit more complex to do
it that way. And complexity is the enemy of maintainability, especially
in my limited staff resources library environment.
But perhaps my perspective is not suff
Actually, thinking about this more, I just came up with a way too clever
method to get my availability checking component (which is actually
Umlaut) to deal with client-side-required APIs. Involving a (re-useable)
hidden div that makes the js API calls, gets the responses back, and
then sends thos
On Mon, 17 Mar 2008, Jonathan Rochkind wrote:
Of course, all these things _can_ be done with only client-side
javascript API. To my perspective, it is quite a bit more complex to do
it that way. And complexity is the enemy of maintainability, especially
in my limited staff resources library envi
My general philosophy is still always to put as _little_ Javascript as
possible. Thus my way-too-clever idea to have some javascript which
actually sends the Google (or similar) API response back to my server
via AJAX for _real_ processing. :)
But if you DO want or need to do javascript-heavy stu
JavaScript as a language has a number of severe limitations regarding
name spaces, dependencies, etc., but well-written, object-oriented
JavaScript as that you'd produce when you build an application using a
library such as prototype actually isn't too bad and (I believe)
provides reasonably good s
environment before printing this e-mail
Van: Code for Libraries namens Godmar Back
Verzonden: ma 17-3-2008 16:21
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
On Mon, Mar 17, 2008 at 11:13 AM, Tim Spalding <[EMAIL PRO
ry.wur.nl/>
P Please consider the environment before printing this e-mail
Van: Code for Libraries namens Godmar Back
Verzonden: ma 17-3-2008 16:21
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
On Mon, Mar 17, 2008 at 11:13
er the environment before printing this e-mail
Van: Code for Libraries namens Jonathan Rochkind
Verzonden: ma 17-3-2008 21:05
Aan: CODE4LIB@LISTSERV.ND.EDU
Onderwerp: Re: [CODE4LIB] Free covers from Google
Interesting that these problems arise even when using the
Hmm, just found an example where Google clearly does something wrong:
Look at: http://library.wur.nl/WebQuery/catalog/lang/948125
It shows a cover and links to the wrong book !!!
The look up is based on isbn 0851992544, but this book has got isbn 0851993575
and this is also clearly stated in the
At 02:55 PM 3/17/2008, you wrote:
My general philosophy is still always to put as _little_ Javascript as
possible. Thus my way-too-clever idea to have some javascript which
actually sends the Google (or similar) API response back to my server
via AJAX for _real_ processing. :)
But if you DO want
I've seen this frequently in publisher data -- especially from small
publishers. Their metadata goes out with the same ISBN for every book
they publish. I don't know if this gets corrected later (I assume it
does to make the ordering process work). My guess is that they send out
the first metadata
found on an incorrect isbn:0851992544
Peter
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Karen Coyle
Sent: dinsdag 18 maart 2008 1:16
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
I've seen this frequently in publisher
lto:[EMAIL PROTECTED] On Behalf Of
Karen Coyle
Sent: dinsdag 18 maart 2008 1:16
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
I've seen this frequently in publisher data -- especially from small
publishers. Their metadata goes out with the same ISBN for every book
> If you can find a public email address
>anywhere or comment form, let us know.
You can send a response to them here:
http://www.google.com/support/librariancenter/bin/request.py
The form seems to be for librarians so maybe they'll understand the
issue and talk to people who may be able to make
08 12:57 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Free covers from Google
>
> > If you can find a public email address
> >anywhere or comment form, let us know.
>
> You can send a response to them here:
> http://www.google.com/support/librariancent
Hooray for Google customer response !
It was not easy to find an appropriate response form on Google's web
site to complain about my problems using the Google Books API. I found a
form that was supposedly for authors and publishers wanting to advocate
their book on Google Books and used it. Google
USA 59717-3320
Ph: (406) 994-6429
[EMAIL PROTECTED]
-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Sebastian Hammer
Sent: Sunday, March 16, 2008 10:32 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Free covers from Google
Is there any word on
34 matches
Mail list logo
