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)