[Koha-devel] RFC: Koha Book Cover System

[Michael Hafen]

Comments inline...

On Thu, 2009-09-17 at 12:29 -0400, Joe Atzberger wrote:
> 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.  
> 

You could conceivably add a cache life-time to the LocalCovers backend.
You will have to store the images somewhere, mysql or memcached would
allow you to set an extra property like that I'm sure.  Doing it on the
file system would be a bit more complex.  Then you would have to be able
to set the cache life-time from the BookCover's individual services
backends, like BookCovers::Amazon would have a ( hard coded? )
cache-life of 24 hours that would be passed to the LocalCovers backend
with the image to cache.

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

This is already a problem I expect.  The solution is to cache images
locally so that subsequent requests pull from our server instead of
Google's.  Having an abstract cover module would probably help this
case.  Images would be cached more readily, and if cascading is built in
then when Google blocks you it will go on to query another service
provider.

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

I agree that we will want to handle this with AJAX.  No sense making the
patron or staff wait for the page to load just for the cover image.
Perhaps we can tie the AJAX request to the BookCovers module?

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

This could be added to the staff interface down the road.  A little AJAX
powered pop-up window to choose the cover image to cache.  That way the
cache could be updated/set manually.  Of course we would then want some
way to store that setting.  Along with the image set a property
basically saying 'staff prefers images for this biblionumber to come
from this service'.

> --Joe
> 

Thanks Joe.  Food for thought :)

> On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall at gmail.com>
> 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
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
-- 
Michael Hafen
Systems Analyst and Programmer
Washington County School District
Utah, USA

for Koha checkout
http://development.washk12.org/gitweb/
or
git://development.washk12.org/koha