Hi Kyle On Fri, Sep 18, 2009 at 11:01 AM, Kyle Hall <kyle.m.h...@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 <reedw...@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.h...@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 <gmcha...@gmail.com> > wrote: > >>> Hi, > >>> > >>> On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.h...@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 > >>> gmcha...@gmail.com > >>> > >> _______________________________________________ > >> Koha-devel mailing list > >> Koha-devel@lists.koha.org > >> http://lists.koha.org/mailman/listinfo/koha-devel > >> > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel@lists.koha.org > > http://lists.koha.org/mailman/listinfo/koha-devel > > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha.org > http://lists.koha.org/mailman/listinfo/koha-devel >
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
