There are times when you might want to have two different releases of DLXS Middleware running at the same time.
Whether you need multiple installations will depend a lot on how you manage you DLXS site locally. These are all considerations in how to install and configure multiple releases of DLXS.
The basic idea is to install the new release into a separate directory not within the directory of the earlier release. When the installer program (Installer.pl) prompts you for your DLXSROOT, give it the new directory you want to create to hold the new DLXS release.
When the installer prompts you for the database type your answer will depend on whether you want to use the CSV database files that live in the install tree for each release or MySQL.
It is not necessary to have separate CSV session file locations (e.g. /tmp/sessions, /tmp/sessionslock) or a separate MySQL sessions table for each of the two different DLXS releases. Note that sessions created by different releases of DLXS are not compatible. This is not generally a problem if you expire sessions regularly.
Next, configure another virtual host under your web server and set DLXSROOT for that virtual host to point to the directory containing the new release. recall what a virtual host configuration looks like.
For example, suppose you have DLXS release 8 installed under /usr/local/dlxs8 and you choose to install DLXS release 10 under /usr/local/dlxs10. You would have the release 8 virtual host (already) configured with:
and you would configure the release 10 virtual host with:
So for release 8 your URL might be: diglib8.somewhere.edu/cgi/t/text/text-idx and your release 10 virtual host might be: diglib10.somewhere.edu/cgi/t/text/text-idx where each URL would run middleware from a different install tree, i.e. a different DLXSROOT.
Data (SGML/XML, image files) and XPAT indexes occupy a lot of disk space. DLXS middleware recognizes the DLXSDATAROOT environment variable so that a given release can point to the data/index/image directories (under obj, idx,img) outside of its own install tree.
If the virtual host for a given DLXS release defines DLXSDATAROOT, that value is used as the path prefix for the obj, idx,img directories. If not, the DLXSROOT value is used for the path prefix.
In the earlier example, in the virtual host for release 10, you could set DLXSDATAROOT to /usr/local/dlxs8 to have release 10 read data from the release 8 install tree.
This scenario requires that the release 8 data be forward compatible with release 10. (More on this when we talk about data preparation for TextClass). If forward compatibility is a problem, the data could be moved to the release 10 tree and pointed to from the release 8 middleware. Then the data could be migrated gradually to work with 10 in a manner that was backward compatible with 8.
There are other possibilities for using DLXSDATAROOT. For example, you could configure more than one virtual host for the same release. One virtual host could use DLXSDATAROOT to point outside its tree while another points at data within its own tree etc.
Another scenario might be to have your data in a single location entirely outside all install trees and use DLXSDATAROOT in every virtual host to point at that single location.