[Koha] Koha and Third-Party commercial services

Scott Kushner skushner at mplmain.mtpl.org
Sun Nov 6 11:56:24 NZDT 2011


Ian, 

 

What exactly are these "services" that you are concerned with...???

 

Scott Kushner

Middletown Library

 

From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Lori Bowen Ayre
Sent: Saturday, November 05, 2011 6:26 PM
To: Ian Walls
Cc: koha
Subject: Re: [Koha] Koha and Third-Party commercial services

 

Ian,

 

This issue came up with Evergreen recently and someone suggested creating an "Vendors Module."  They wrote up how it would work....maybe some useful ideas there.

 

See http://egdev.mvlcstaff.org/Vendors_Module

 

Lori


 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=

Lori Bowen Ayre // 

Library Technology Consultant / The Galecia Group

Oversight Board & Communications Committee / Evergreen

(707) 763-6869 // Lori.Ayre at galecia.com

 

Specializing in open source ILS solutions, RFID, filtering, 

workflow optimization, and materials handling 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=





2011/11/5 Ian Walls <ian.walls at bywatersolutions.com>

Dear Community,


In the last few months, I've seen more and more interest in developing Koha support for integration with third-party commercial services.  These services usually require some kind of special coding to achieve that integration, instead of using a global standard for data transmission.  To be fair, I think this is often because there IS NO global standard for the kind of data they want to transmit.  But I'm still wary of this.

All the external services we have now (Amazon, Babelthèque, Baker and Taylor, Google, Library Thing, Novelist Select, OCLC, Open Library, and Syndetics) are very self-contained; they have system preferences which just control whether or not a block of HTML/Javascript API code gets put into the template.  This is pretty benign; it's template code and some database data (nothing structural), and can be completely disabled if the preferences are turned off.  This seems like good integration to me.

But other services require something a bit more heavy-weight.  Things that would involve writing a fair block of Perl code, or altering Koha's data structure to store a new kind of information (new table columns or tables, instead of just entries in existing tables).  Changes like this concern me, particularly if the service requires a subscription, is geographically-limited or has closed licensure.  Perhaps I'm just being paranoid, but it seems that if we start letting these external services influence the development of Koha, we could eventually wind up with an ILS that is no longer in the interest of the global community.

Am I being crazy?  Is this a valid issue?  Are the advantages of being able to talk to more external products greater than the risks of a few specific company's products getting hardcoded into our ILS?

Thanks for any feedback you can provide,


-Ian



_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katipo.co.nz/pipermail/koha/attachments/20111105/34477d96/attachment.html>


More information about the Koha mailing list