[Koha] Proposed new cgi directory structure

[Roger Buck]

PURPOSE OF THIS THREAD:
To examine options for revision of koa cgi directory tree

CURRENT SITUATION:
Koha is designed to be installed as two separate services - each having
a unique web address and folder structure (two virtual web hosts). The
folder structures for both servers are designed to operate separately
and independently; The only reason for this is to simplify security.

Currently both services access a single SQL database which may be hosted
on the same server or on a remote server. The two separate web servers
are referred to as "koha" and "opac" ("koha" refers to the on-line admin
interface whilst "opac" refers to the on-line public access catalogue
interface). The term "intranet" in the koha doc refers specifically to
the "koha" web site.

PROBLEM:
Koha is designed to operate in two independent web spaces - this can add
complexity to installation, security and maintenance.

REQUIREMENTS:
Any departure from existing structure must provide significant benefits
whilst minimising changes to existing code base.

AIMS:
To allow for clarify terminology and layout leading to simplified koha
installation, security and administration:


PROPOSED NEW DEFINITION FOR "koha":
The current usage of "koha" is muddled: The current service referred to
as "koha" (also referred to as Intranet) should be re-named to something
like "oadmin" (on-line admin). The term "koha" then is free to
encompasses both the "opac" and "oadmin" services.


Example 1. Current cgi tree:

 cgi-bin / - koa
        
 cgi-bin / - opac         



Example 2. Proposed new cgi tree structure:
                              
 cgi-bin / koha /- C4
                |                       
                /- oadmin
                |
                /- opac


If the new tree structure is adopted, then I'd suggest a similar change
to the htdocs tree structure might be fruitful (but that's a separate
issue).

Without going into detailed explanations of reasoning (except on request
;^)...

Example 2 may offer the following advantages:
 1. The directory names relate more closely to function.
 2. More flexible - Same config setup for both single and dual services
 3. All project specific perl stuff stored in single folder
 4. Simpler apache configuration
 5. Simpler installation for hosting (especially 3rd part hosting)
 6. No reduction in security / authorisation options.


Example 2 offers following disadvantages:
 May require some re-coding of hard-coded paths.


What changes are required to support proposed new structure?:

Option 1 - No change required to koha code, all changes can be affected
solely by editing paths / aliases in webserver config file (httpd.conf).
This is probably not strictly true as some paths may be hard-coded in
existing koha code... but it would be better if all hard-coded  paths
could be reduced to relative paths anyhow.


Option 2 - Extend the /etc/koha.conf file to support additional path
variables.


Option 2 offers benefit of simplified configuration using a conventional
style, single user editable config file whilst significantly simplifying
webserver config requirements. The current koha.conf file does not
require additional development at this time - just a possible
development direction for the future if this proposal is adopted.


Does anyone see any fundamental problems with proposed changes?

If there is positive feedback to this proposal, I'll follow up with a
_lot_ more detail... otherwise I'll re-evaluate afresh without wasting
everyone's time ;^)

Feedback please?

R.