IIRC, Amazon was pretty strict about caching, limiting you to holding images for only 24 hours. That makes building a system around it significantly less desirable.
The other problem you will have is that if the server is fetching all the images from Google, a busy site will trip their anti-harvesting protection and get the IP blocked. Ideally, I'd want all the jacket requests and cascading to be happening on the client side. Barring that, it at least has to be part of an AJAX request to the Koha server. Otherwise you're blocking the entire page load while you are waiting serially for 4 or 5 (or more) servers to respond. The reason you can't just do it as a dynamic response to a regular HTTP .jpg request is that you are obligated by all (or almost all?) the terms of service to put a link and/or a credit attribution in there when the image is displayed. And of course you wouldn't know ahead of time which link/credit it would be, and the dynamic response to a static request would effectively conceal the original source such that no client side logic could be used. We should also go ahead and say whether the proposed system will support showing multiple jackets (for the same item) simultaneously. I imagine that would be the single best way to evaluate the coverage and quality of various sources, to know which to enable, and in what priorities. --Joe On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <[email protected]> wrote: > Hey All, > Writing the LibraryThing book cover module has really got my brain > in full gear. I've been thinking about how nice it would be to add an > internal cover system to Koha. That way, a library could specify the > exact cover they want if they so wish. Here's what I'm imagining. > > A new ItemImages.pm ( BookCovers.pm, BookJackets.pm, what have you... ) > > This new Covers module would be the sole interface for Koha for all > cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act > as an interface between Koha and the book cover modules. > > Another module ( say LocalCovers ) would act as a caching system. > Librarians would then at the time of cataloging, but able to search > various sources for book jackets, and choose one to download and save > for that bib record. > > A set of preferences would allow for a cascading selection of sources > from which to display book covers. For example, a library could have > the system set up to look for a locally stored book cover first. If > one is not found, it checks LibraryThing for one, if one is not found > there, it then uses an Amazon book cover. > > Possible Issues: > Do any of the cover API's have Terms of Service that could pose a > problem to such an system? ( For example, can we cache amazon.com > images, or must they always be links? ) > The existing C4::External modules would need to be modified. > Where should local/cached covers be stored? Filesystem and/or MySQL blob? > > Any and all opinions welcome, > Kyle > > http://www.kylehall.info > Information Technology > Crawford County Federated Library System ( http://www.ccfls.org ) >
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-devel
