[Koha] Re: [Koha-devel] For the (non)coder

[Tonnesen Steve]

On Tue, 6 Nov 2001, Nicholas Stephen Rosasco wrote:

> Is there any sort of target goal/date (I know MARC/z39.50 "completeness"
> is coming along soon -- what a fantastic tool that is!  thanks!!!) for
> getting a new version packaged, and are any translation issues for the
> database for the new format expected?

Chris, of Katipo fame, is trying to convince me to package up a new
release.  I'll probably give it a shot.  There are a couple of technical
issues that I need to work out:

1.  how to start the Z39.50 daemon, and make sure it keeps running.  There
    are also some issues that I need to work out with the daemon itself.
    Every once in a while it likes to redo all the old queries.  :)
2.  how to install the YAZ and Net::Z3950 packages.
3.  script to update existing Koha databases (very scary!  Will probably
    have an option to allow backing up the existing databases before doing
    the upgrade).  
4.  Need to move away from DebConf for configuring the Koha package.  I
    like debconf, but it just isn't portable enough.  In its place I'll
    have a script that needs to be run after installing the package (be it
    deb, rpm, or tarball).
5.  Need to set up a preferences configuration system so that Koha admins
    can change system preferences (like which acquisitions module to use).
6.  Need to give some thought to integrating the two acquisitions modules
    so that librarians can use either one at any time.
7.  Permissions controls.  This is a big one.  I'm not sure how HDL does
    this, but I have a separate package called K12Admin that I use to
    create accounts for all staff and students in my schools.  I use this
    package to populate the membership database of Koha, and to create an
    apache password file for authenticating to the librarian interface.
    How should this be handled in the generic case?  I'm guessing that
    there should be a superuser account that gets created when the package
    is installed that has access to everything, and the "Members" section
    needs to be modified to allow passwords to be stored for users, as
    well as librarian permissions to be granted.  As I said before, this
    isn't a particular itch of mine, as all of this is taken care of by my
    K12Admin program here.


I could probably have a package together this week that didn't take of 1,
2, 5, 6 or 7.  Actually, 7 could be semi-taken care of with the superuser
idea.  Then there would be one account that had access to the librarian
interface. 

Anyway, just some random thoughts to get me moving...


Steve