[Koha-devel] we've got a winner :-) => IMPORTANT

[Roger Buck]

> 
> On Thu, 3 Oct 2002, paul POULAIN wrote:
> > About parameters :
> > -------------------------
> > I think we're on a dangerous way... some parameters are in
> > /etc/koha.conf, some are in systempreferences table.

> Andrew Arensburger wrote:
> On the whole, I agree that /etc/koha.conf should contain as little
> as possible. I'm just trying to come up with scenarios in which it would
> make sense to put additional stuff in /etc/koha.conf.

We run three independent Kohas on a single web server. This requires
three separate copies of koha.conf (hardwired in Output.pm). This also
requires that we run six virtual hosts and a complicated file structure
with lots of duplication. This also means that I have spent a lot of
time evauating various options for file structure and configuration.

We don't experience the same difficulties with other web based services.

I think that a re-organistaion of the koha file structure couldhelp
reduce  complexity - thus simplifying the config options and reducing
complexity for programming, installation, maintenance and security.

As a basis for discussion, this is the type of file structure we'd
suggest:

/usr/local/www/htdocs/koha
                          ./* (shared)
                          ./opac
                          ./opac/includes
                          ./opac/templates

                          ./intranet
                          ./intranet/includes
                          ./intranet/templates


/usr/local/www/cgi-bin/koha
                          ./* (shared)
                          ./C4
                          ./opac
                          ./intranet


/usr/local/www/htdocs/koha/images
                          ./* (shared)
                          ./opac
                          ./intranet

IMO, the advantages of this type of layout are:

 1. Easily integrated into  pre-existing web user space (no additional
virtual host(s) required)

 2. Folder based differentiation between "opac" and "intranet" (rather
than current virtual host based differentiation)

 3. More differentiation between "opac" and "intranet" specific
resources.

 4. Identifiable folders to contain shared (opac versus intranet)
resources of all types.

 5. Path based configuration options independent of virtual host aliases

IMO, the one disadvantage is that more configuration options will need
to be set to replace the separation currently provided by virtual host
aliases. This may appear to be onerous... but I think the present
structure gives a false feeling of security/logic - the separation
between "opac" and "intranet" resources are somewhat more blurred than
they appear to be at face value.

Again, my reasons for considering the above is that Koha configuration
seems potentially complex (compared with other web based services that
we run).

I would like to propose some more detailed changes but after having a
look at CVS structure over last week - I can't get my head around what
the current file structure actually _is_ ;^)

I am not a programmer so have probably totally overlooked lots of
important problems associated with above. I am happy to do more work on
this given some direction....

R.