Ze względu na użytkowanie Koha przez w iele rozm aitych instytucji z całego św ia ta, zaim plem entow any został szereg protokołów - zarów no typowo bibliotecz nych, ja k i ogólnie stosowanych.
Do autoryzacji użytkowników, poza standardow ym użyciem loginu i hasła, moż na w ykorzystać protokoły:
• LDAP • C A S • Shibboleth • M ozilla Persona.
Konfiguracja i sposób w ykorzystania powyższych protokołów zależy oczywiście od konkretnej instytucji.
Kolejny rodzaj protokołów je st ściśle zw iązan y z obsługą biblioteki. Zdefiniow a ne są w nich polecenia dotyczące obsługi czytelników, w ypożyczeń, zwrotów ksią żek itp. O becnie dostępne są dwa tego typu protokoły. ILS-DI (Integrated Lib rary System - D iscovery Interface), protokół stw orzony przez DLF (Digital Lib rary Fun- dation) w celu ustan daryzow an ia komunikacji pom iędzy system am i bibliotecznymi oraz usługam i z nimi w spółpracującym i. Zaim plem entow ano niem al w szystkie po lecenia definiowane przez protokół. O becnie nie są prowadzone żadne prace nad rozwojem tej funkcjonalności.
Jednym z ciekaw szych protokołów udostępnianych przez Koha je st SIP2 (Standard Interchange Protocol). Je s t to protokół opracow any przez firm ę 3M , początkowo na potrzeby w spółpracy ich urządzeń z system am i bibliotecznym i. Specyfikacja została je d n a k udostępniona przez producenta, dzięki czem u w niedługim czasie sta ł się on standardow ym protokołem. O becnie jego obsługą może pochw alić się w iększość zin tegrowanych system ów bibliotecznych. U żyw any je st przede w szystkim do obsługi czytelników przez stacje sam oobsługi oraz do w spółpracy z system am i RFID . Koha obsługuje oba rodzaje usług. Do prawidłowej pracy w ym ag an a je st odpowiednia, w zależności od u rządzenia, konfiguracja se rw era SIP2 dostarczanego w ra z z Ko ha. W sp ó łp raca ze stacjam i sam oobsługi może być realizow ana przy użyciu sa mego system u bądź z w ykorzystaniem oprogram ow ania dostarczanego przez producenta u rządzenia. W takim przypadku w ykorzystyw any je s t do komunika cji protokół SIP2.
W sp ó łp raca z RFID obecnie je s t nieco mniej rozwinięta. W iększych problemów nie przewiduje się przy korzystaniu z usług RFID dedykowanych dla bibliotek. Ta ka konfiguracja je st spraw dzona i używ ana przez co najm niej kilkanaście bibliotek na św iecie. Ko rzystając z gotowych rozw iązań dedykowanych, dostajem y w pakie cie, poza sam ym i urządzeniam i do czytania kodów RFID, oprogram ow anie za p ew niające pełną funkcjonalność takiego system u. Dodatkowe oprogram ow anie jest obecnie niezbędne do prawidłowej i pełnej w spółpracy Koha z system em RFID. Jed n akże trw a ją prace nad im plem entacją RFID bezpośrednio w system ie Koha. Dzięki takiem u rozw iązaniu do w drożenia system u RFID w bibliotece w ysta rcza ją c y będzie czytnik oraz tagi RFID . Rozw iązanie takie je st oczywiście dużo tań sze od system u dedykowanego. Przykładowe w drożenie tego typu rozw iązania zo stało przedstaw ione przez Dobricę Pavlinusicia [Pavlinusić, 2 0 1 5 ]. U żyw ane jest obecnie przez co najm niej je d n ą bibliotekę. Kod źródłowy je st dostępny w form ie repozytorium G it, pod adresem h ttps://g ithub.com /dpavlin/Biblio-RFID . Drugie, podobne rozw iązanie zaim plem entow ane zostało przez pracowników O slo Public Library. Dokum ent opisujący tę im plem entację dostępny je st pod adresem http:// w iki.ko ha-co m m un ity.o rg /w iki/R FID _R FC , sposób działania je st podobny do tego zaproponow anego przez Pavlisnusicia. Również i w tym przypadku kod je st ogól
nodostępny. Nie ma natom iast inform acji o wdrożeniu tego rozw iązania w środo wisku produkcyjnym, system je st ciągle w fazie testów i rozwoju.
Pozostałe protokoły dostępne w Koha dotyczą różnego rodzaju udostępniania bądź pobierania danych bibliograficznych. D o daw anie danych bibliograficznych do system u możliwe je st poprzez protokoły Z 3 9 .5 0 oraz SRU (Search/Retrieve via U RL). U dostępnianie danych bibliograficznych możliwe je st przy użyciu protoko łów Z 3 9 .5 0 oraz O AI-PM H. O bsługa Z 3 9 .5 0 m ożliwa jest, ja k ju ż zostało w cześniej w spom niane, dzięki oprogram ow aniu Zeb ra. Protokół OAI-PM H obsługiw any jest bezpośrednio przez sam system Koha. Poza w łączeniem w opcjach obsługi OAI- PM H, nic więcej nie w ym ag a konfigurowania, nie ma również potrzeby przeindek- sow yw ania danych bibliograficznych.
8.
Rozwijanie systemu Koha
Do utrzym yw ania kontroli nad kodem źródłowym używ any je s t system kontro li w ersji G it. Repozytorium kodu Koha je st dostępne dla każdego w trybie tylko do odczytu. U praw nienia do za rzą d za n ia repozytorium po siadają w ybrani członkowie społeczności. D la każdej kolejnej wersji głównej (tzw. m a jo r re le a se ) w ybierany jest spośród społeczności zespół osób spraw ujących pieczę nad w ydaniem oraz osoba odpow iedzialna za w ydanie (release m a n a ger). W yb o ry odbyw ają się zazw yczaj po każdym w ydaniu nowej w ersji (co ok. 6 m iesięcy: m aj i październik) na kana le IR C #koha. D odanie jakiejkolw iek poprawki do repozytorium w ym ag a przejścia przez procedurę „form alną" stosow aną przez społeczność. W yg ląd a ona, w skró cie, ja k poniżej.
Pierwszym , najw ażniejszym krokiem je st zgłoszenie odpowiedniego błędu (na w et jeśli zm ian a ma dotyczyć tylko rozszerzenia funkcjonalności system u) w syste mie za rzą d za n ia błędam i Bugzilla. Zgłoszenia m ogą być dodaw ane przez każdego zarejestrow anego użytkownika. Zgłoszenie błędu powinno zaw ie rać:
• kroki niezbędne do odtw orzenia, czyli ja k a była dokładnie ścieżka działań w system ie przed w ystąpieniem błędu,
• inform ację o błędzie podaną przez system, o ile taka się pojawiła; ewentu alnie - ja k system zareag ow ał na działania inform atyków w stosunku do zm ian oczekiwanych,
• (ew entualnie) załączn ik obrazu lub filmu z nieprawidłowym zachow aniem system u.
Przy zgłaszaniu rozszerzenia należy opisać nowe funkcje, zm ian y interfej su, dodane lub m odyfikowane preferencje system owe. D odaw anie funkcji zm ie niających działanie system u musi być zaw sze opcjonalne. Nowe w ersje sys temu nie m ogą zm ieniać aktualnie działających funkcji bez w yraźnej zgody
ad m in istrato ra lub bibliotekarza system owego. W związku z tym nowe funkcje w system ie są dodawane, ale dom yślnie wyłączone.
Poprawka (patch) błędu/zgłoszenia dodana może być przez każdego chętnego, niekoniecznie musi to być osoba zg ła sza ją ca . Powinna za w ie ra ć m iędzy innymi ele m enty takie ja k : num er błędu nadany przez Bugzilla, tytuł w form ie krótkiego pod sum o w ania o raz opisu błędu, najczęściej takiego ja k w zgłoszeniu. Ponadto p atch powinien za w ie ra ć „plan testów", to je s t dokładny opis, ja k ie kroki należy wyko nać, aby przetestow ać działanie poprawki i móc stw ierdzić, że istotnie n ap raw ia / rozszerza funkcjonow anie system u oraz nie w prow adza regresji (utrata w cześniej szych funkcjonalności, w prow adzenie nowych błędów).
Kolejnym etapem , je s t „podpisyw anie" poprawki. Polega ono na przetestow a niu poprawki przez inną osobę. N ajczęściej testow anie polega na wykonaniu „pla nu testów" załączonego do p a tch a . Jeżeli testy w yp ad ną pomyślnie, poprawka może zostać podpisana, czyli zatw ierdzona jako spraw dzona i d zia łająca zgod nie z założeniam i jej autora. W edług obecnych zasad zatw ierd zania poprawek preferuje się, chociaż nie je s t to w aru n ek konieczny, aby podpis składała osoba n iezw iązana z firm ą /o rg a n iza cją autora poprawki. Pozwala to do pewnego stop nia uniknąć sytuacji, gdy zm iany forsow ane są przez jednego producenta. Nie stety obecnie, ze względu na zbyt m ałą liczbę wolontariuszy, dopuszcza się od stęp stw a od tej reguły. O kazuje się bowiem, że program istów zg łaszających swoje poprawki je s t dużo w ięcej niż w olontariuszy testujących te zgłoszenia. Z jednej strony sp raw ia to, że kod Koha rozwijany je s t dość szybko, ale z drugiej - ciekawe i potrzebne funkcjonalności oczekują stosunkowo długo na dołączenie do o ficjalne go w yd an ia. Po podpisaniu przez co najm niej je d n ą osobę, status błędu zm ienia ny je s t na sig n e d -o ff (podpisany) i oczekuje on na ostateczną akceptację przez ze spół ds. jakości (Q A - Q u a lity A ssu ra n ce ). Członkowie zespołu Q A w ybierani są na w cześniej opisanych za sa d a c h . N ajczęściej w ykonyw ana przez nich praca ma cha rakter w olontariatu. Są oni odpowiedzialni za jako ść kodu, który zostanie dołączo ny do Koha. Spraw dzana je st przede wszystkim popraw ność „form alna" kodu przy użyciu n arzędzia koha-qa.pl. Spraw dza ono, czy p atch je s t sform atow any popraw nie, czy nie zaw ie ra błędów kom pilacji. W ykryw an e są również niektóre przestarza łe konstrukcje używane w kodzie, niedozwolone znaki itp. N astępnie spraw dzane są podstawowe funkcjonalności system u przy użyciu testów jednostkow ych. M ają one na celu w ykrycie ewentualnych regresji. Utw orzenie procedur testów jednost kowych je s t obecnie w ym ag ane dla niem al każdej nowej funkcji/p ro ced ury/m e to dy/klasy dodawanej do bibliotek w Koha. O dstępstw a od tej za sa d y są rzadkie i niechętnie przyjm ow ane. Jeżeli w poprawce dodaw ane są nowe funkcje i braku je testów jednostkow ych, najprawdopodobniej zostanie ona za trzym a n a do czasu dodania potrzebnych testów. Patch sp raw d zan y je s t również, według załączonego
planu testów, w ten sam sposób ja k w cześniej przez osobę podpisującą popraw kę. O statnim i elem entam i spraw dzanym i przez zespół Q A je s t ogólna jako ść kodu, zgodność z za sad a m i przyjętym i przez społeczność, m .in. konwencja nazw zm ien nych, nowe procedury w odpowiednich m odułach, spraw dzenie, czy podobne pro cedury ju ż istnieją w bibliotekach i itp. Jeżeli pojaw ią się zastrzeżenia do poprawki, inform acja odnośnie do tego, co należy popraw ić, zostanie um ieszczona w komen tarzu do tego błędu w system ie Bugzilla. Po w ym aganych m odyfikacjach doda je się nową „popraw kę do popraw ek". Przechodzi ona tą sa m ą procedurę co in ne poprawki, chyba że zm iany w niej za w a rte są kosm etyczne (literówka, zm iana nazew nictw a, fo rm ato w ania). Jeżeli pojaw ią się zastrzeżenia do ogólnego sposo bu rozw iązania problemu lub w prow adzanej nowej funkcji przez poprawkę, błędo wi może zostać nadany status In discussion (do om ów ienia), gdzie każdy ma pra wo się w ypowiedzieć i przedstaw ić sw oją w izję działania om aw ianego fragm entu system u. Rozwiązyw anie tego typu problem ów je s t je d n a k bardzo czasochłonne - może trw a ć naw et kilka lat.
Jeżeli w szystkie poprzednie etapy zakończyły się pomyślnie, popraw ka uzyskuje status P a ssed Q A. O zn acza to, iż może zostać w łączona do kodu Koha przez me nadżera w ersji. N ajczęściej tak w łaśnie się dzieje. W sporadycznych przypadkach popraw ka może zostać odrzucona, z różnych względów. Poprawki i rozszerzenia funkcjonalności dodaw ane są przede wszystkim do w ersji bieżącej, tzw. m aster. Je s t to najbardziej aktu alna w ersja, z której w ydzielane są następnie w ersje głów ne. W przypadku popraw ek m ogą być one b a ck p o rto w a n e do w cześniejszych w er sji, jeżeli błąd również w nich w ystępow ał. Z za sa d y nowych funkcji nie dodaje się do istniejących ju ż w ersji głównych.