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.