Re: [Koha] Koha and Third-Party commercial services
On 2011-11-6, at 4:26 AM, Scott Kushner wrote: Ian, What exactly are these “services” that you are concerned with…??? didn't Ian give examples in his previous email... All the external services we have now (Amazon, Babelthèque, Baker and Taylor, Google, Library Thing, Novelist Select, OCLC, Open Library, and Syndetics) PGP.sig Description: This is a digitally signed message part ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha and Third-Party commercial services
Ian, What exactly are these services that you are concerned with...??? Scott Kushner Middletown Library From: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@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 workmaybe 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.a...@galecia.com Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2011/11/5 Ian Walls ian.wa...@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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Koha and Third-Party commercial services
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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha and Third-Party commercial services
Hi Ian, 2011/11/5 Ian Walls ian.wa...@bywatersolutions.com 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? The point is well taken. However, I tend to think that if we were to isolate the unique code for external product Z to something like C4::ExternalServices::Z. and the database fields unique to a new table Z, this would sort of quarantine any undesirable aspects of product Z. The installation of the schema for table Z could be triggered by both a choice in the installer or the running of an separate install script (install_z) later by the sys-admin. The installer would simply call install_z if the choice was made at install time. install_z would recognize that the db was populated (if this were a later addition) and handle any db housework accordingly. Furthering this thought of convenient abstraction, we could have C4::ExternalServices which would provide basic API between Koha and the various C4::ExternalServices::FOO modules. Whatever way we take, quarantining/abstraction should help keep your fear from being realized. Kind Regards, Chris ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha and Third-Party commercial services
* Mirko (5...@gmx.de) wrote: I think Ian has a valid point here, you are definitely not paranoid. It is a concern to me too and I like the quarantine approach Chris has offered. There are a lot of services integrated already and personally I wish to keep all the snoopy data gatherers like Amazon, Google etc. out of my library and away from my patrons. Their omnipresence in the WWW is scary enough as it is, I don't want to assist them in any way. I think some kind of guidelines should be set up making sure that third party services don't get to mess with integral parts of Koha, that no other developments get 'harmed' by new code for something that only a certain group of people will use (this would be prevented by Koha quality control anyway) and that those who do not want to use a service don't have extra work (like disabling new third party features in a new version). C4::ExternalServices approach sounds good to me and I strongly favour keeping extra database fields in extra tables dedicated to the service, so Koha core does not get cluttered with extra fields for Facebook, Google and whatnot. I agree, the quarantine idea is a good approach. As most of you know I am not a huge fan of proprietary software in any shape, way or form. I would like us to try integrate with free software tools where we can, like Piwik instead of google analytics, identi.ca instead of twitter and many others. (commercial doesnt worry me, theres nothing wrong with that, its proprietary software I dont like). But if we do have to deal with proprietary software, it must be in a quarantined and safe way. Just my 2 cents Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand signature.asc Description: Digital signature ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
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 workmaybe 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.a...@galecia.com lori.a...@galecia.comSpecializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2011/11/5 Ian Walls ian.wa...@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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
