[Koha-devel] RFC: Koha Book Cover System

[Rosalie Blake]

Hi Kyle

On Fri, Sep 18, 2009 at 11:01 AM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> What I have in mind would make selecting images optional. Here is a
> thought scenario: Let's say that you prefer to use amazon images for
> your book covers, but a few books have no cover or the wrong cover
> from amazon. In this instance, you would be able to upload an image
> locally, or force that bib to use a different service for it's book
> cover.
>
> So, rather than requiring you to add covers to each bib by hand, you
> could cascade through different cover options. Check for local image
> first, if not found, use amazon.
>
> Does that sound like a good idea?
>

I think it's a brilliant idea
Cheers
Rosalie Blake

>
> Kyle
>
> http://www.kylehall.info
> Information Technology
> Crawford County Federated Library System ( http://www.ccfls.org )
>
>
>
>
> On Thu, Sep 17, 2009 at 6:31 PM, Reed Wade <reedwade at gmail.com> wrote:
> > Selecting and storing images locally for all holdings sounds like a pain.
> >
> > I can imagine a cooperatively held db (hello, koha foundation) of
> > records that look like:
> >
> > isbn/issn/other globally unique id that identifies the holding in a
> > way that makes searches possible
> > url to images (front, back, etc) - maybe they're on flickr, or in amazon
> land
> > image license and/or attribution statement
> > caching limits
> > who updated
> > when updated
> >
> > And some simple REST style api that allowed a module to display the
> > attribution and use the image url directly for display or via a
> > (potentially caching) proxy for local library networks that might
> > require it.
> >
> > And a mechanism for adding/updating records to the cooperatively held
> > db. And for automatically using them maybe based on who updated them
> > in case some folks turn out to be bad at it.
> >
> > A variation -- instead the central db providing the look up service.
> > It could provide just the collective DB with your local koha instance
> > subscribing to updates. So, the user load of the lookup is local but
> > we get the benefit of sharing the effort of selecting images.
> > (Reinvention of usenet data flow architecture sort of.)
> >
> > -reed
> >
> >
> >
> >
> > On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall at gmail.com>
> wrote:
> >> Excellent ideas all around. I suppose it could be written as a CPAN
> >> module which would then be used in Koha.
> >>
> >> Kyle
> >>
> >> http://www.kylehall.info
> >> Information Technology
> >> Crawford County Federated Library System ( http://www.ccfls.org )
> >>
> >>
> >>
> >>
> >> On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt at gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall at gmail.com>
> wrote:
> >>>> 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.
> >>>
> >>> Good idea.  It occurs to me that this could be *very* loosely coupled
> >>> to Koha and done as a component that could be used by other
> >>> applications, as all that it would need from Koha itself are some
> >>> configuration settings and some information from each bib record to
> >>> grab covers for.
> >>>
> >>> Regards,
> >>>
> >>> Galen
> >>> --
> >>> Galen Charlton
> >>> gmcharlt at gmail.com
> >>>
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at lists.koha.org
> >> http://lists.koha.org/mailman/listinfo/koha-devel
> >>
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha.org
> > http://lists.koha.org/mailman/listinfo/koha-devel
> >
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090918/a9e3f13c/attachment-0003.htm>