Hi Ian,<br><br><div class="gmail_quote">2011/11/5 Ian Walls <span dir="ltr">&lt;<a href="mailto:ian.walls@bywatersolutions.com">ian.walls@bywatersolutions.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>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&#39;s products getting hardcoded into our ILS?<br></blockquote>

</div><br><br>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 &quot;undesirable&quot; 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.<br>

<br>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.<br><br>Whatever way we take, quarantining/abstraction should help keep your &quot;fear&quot; from being realized.<br>

<br>Kind Regards,<br>Chris<br>