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
Hi Ian, 2011/11/5 Ian Walls <ian.walls@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
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. Thank you for bringing up this discussion! Mirko schrieb Chris Nighswonger am 05.11.2011 13:15:
Hi Ian,
2011/11/5 Ian Walls <ian.walls@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
* Mirko (5p4m@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
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@galecia.com <Lori.Ayre@galecia.com>Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2011/11/5 Ian Walls <ian.walls@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
Ian, What exactly are these "services" that you are concerned with...??? Scott Kushner Middletown Library From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@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@galecia.com Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2011/11/5 Ian Walls <ian.walls@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
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)"
Not really.. If I'm not mistaken, those were the ones that he didn't have a problem with, as I read it... -----Original Message----- From: Mason James [mailto:mtj@kohaaloha.com] Sent: Tuesday, November 08, 2011 2:23 AM To: Scott Kushner Cc: koha@lists.katipo.co.nz Subject: 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)"
On 2011-11-8, at 7:47 PM, Scott Kushner wrote:
Not really..
If I'm not mistaken, those were the ones that he didn't have a problem with, as I read it...
-----Original Message----- From: Mason James [mailto:mtj@kohaaloha.com] Sent: Tuesday, November 08, 2011 2:23 AM To: Scott Kushner Cc: koha@lists.katipo.co.nz Subject: 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)"
oops, yes..., i re-read Ian's email, and you are right :)
participants (7)
-
Chris Cormack -
Chris Nighswonger -
Ian Walls -
Lori Bowen Ayre -
Mason James -
Mirko -
Scott Kushner