1. InstallMgr Some time ago it was mentioned that the backend functionality of the InstallMgr would be integrated in the sword library to ease the creation of frontend-specific Installation Tools. How is the status of that integration? Is it still wanted? If so, when could we expect this to be done?
I'm asking because the BibleTime team plans to create such an Installation Tool for KDE/QT _really soon_. We would be happy to use the backend functionality in sword, but we can do without as well. So please let us know your plans. If nobody replies I'll assume the plans died, and we'll implement our own solution, though I'd prefer collaboration on this particular topic. 2. CVS May I ask for the cvs split to be executed? It really makes a lot of sense to slit up the main repository into parts that form logical units, such as lib (including examples), apps, tools etc. The main "sword" cvs module should be as slim as possible while keeping the stuff necessary for developing and building the main sword lib, for not all have that fast internet connections. 3. ICU We need to think about ICU integration in sword. For reasons I already explained here (and can explain again if you want me to) I refuse make BibleTime dependant on ICU as long as it is not the standard ICU distribution (which it isn't) or as long as it is integrated in sword directly. Why should we integrate it? It makes the whole installation process far more easy for users and frontend developers. My proposal: -Integrate the whole (patched) ICU source and data tree in sword and make it permanently dependant on ICU. -Then we could have switches to "configure", which turn off the inclusion of ICU datafiles (except dummy files) in the released packages. Thereby the installed binary will probably stay small enough for handheld devices, while offering a consistent API. -If you also wish to exclude the ICU sources, we will need to introduce wrapper classes which make compiling possible for frontends no matter if ICU is included or not. Thanks for your consideration and replies. Martin
