[Koha-devel] The future of Koha (some ideas and thoughts) [IMPORTANT] (I hope) and [LONG] (not so)

[Paul POULAIN]

Hello all,

I was in Paris yesterday (what does not justify a mail on koha-devel, I 
agree ;-) ), and was thinking to the future of Koha in the TGV (3hours 
to do 850km !)

I suddenly realized that, with the architecture we are working on for 
Koha 3.0, we were on the way to develop what I call "Koha-Suite".

I mean in Koha 3.0, we will have :
* a web portal. (Our actual OPAC)
* a tool to store large datas (Zebra)
* all ILS features.
We spoke once to have RSS feeds in OPAC, I'm sure that's a great idea 
that could be implemented quite easily in Koha and highly improve OPAC 
use & utility.
Once rss feeds will be availabe in OPAC, we could consider Koha 
interfaced with any CMS, as most actual CMS are providing rss feeds. We 
could imagine "rss boxes" in main page as well as in opac-user page. 
Just a suggestion for instance, it's not done (except in some 
argentinian code, iirc)

So we have a software in 4 parts.
All of them can be modularized to consider we have 4 differents bricks 
that can be foundation of a complete document-oriented-suite.

What we could add later is :
* a brick to manage electronic document (like thesis & internal 
production of the user-company) Internal docs as well as OpenArchive 
harvester.
* a brick to index external sources, that could be sorted & analyzed to 
do a knowledge DB (in french, it's "veille technologique", that I don't 
know how to translate. I mean : a tool that automatically check some 
databases daily, compute summaries on accurate documents, and send them 
to users)

Of course, the 2 later bricks won't be written in a day or 2. Not even 
in this month. And probably not for 3.0

But I'm sure (& hope you will confirm) that it's the way to go. If 
confirmed, then Koha developpers will have to write all 3.0 stuff with 
this goal in mind, on the long term.

It means having a code structure modular enough to be able to install a 
brick without all the others.

Just one technical proposal, about code organization :
We could have, under koha-cvs, one directory for each brick :
* /opac/ for web portal (yes, we already have it !!!)
* /core/ for the common and core scripts (I think actual modules : 
parameters, reports and members)
* /ils/ for ils part of Koha suite (I think actual acquisition, 
cataloguing, circulation, authorities)
* /XXX/ for electronic docs management (new brick, does not exist yet)
* /YYY/ for external source (KB) (new brick too)
* The /C4/ directory contains every core Perl packages and will be a 
common tool, used by every brick, so it can stay on top level of CVS org.

With such an architecture it would be easy to release specific packages, 
for "Koha ILS-only", "Koha KB-only", "Koha ILS and electronic doc 
management" ...

I have created a little scheme to explain my idea (maybe a basis for a 
future marketing document ;-) ) You can find it on : 
http://___www___.paulpoulain.com/Koha_futur.pdf (remove the trailing ___ 
before and after www, I just want this link not to be indexed by google)
Don't distribute this doc outside from this list for instance pls, it's 
my idea, not the Koha team decision ;-)

-- 
Paul POULAIN
Consultant indépendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)