Executive Summary

1. The CC has acquired a new server to be our web server.
2. This is a good time to re-organise our website.
3. We should use a version control system to keep track
   of changes.

Current Problems

Our website (like the IMSc network) has grown organically rather than logically. While there is nothing wrong with that per se, an examination of our web site shows that:

1. Our apache config file is messy and hence difficult to read and/or modify.
2. Web pages are edited, added, discarded without any clear logs of who did what and why and when.
3. A number of our web pages fail to comply with W3C standards for HTML.
4. A number of our web pages/images have no clear copyright. In particular, it is not clear that we can legally distribute them.
5. There are broken links. Conversely, there are files in the web directories which are never referenced.
6. There is a lot of out-of-date information in our web pages. We have no system to keep track of short-term info.

Since we are planning to install a new web server on the new server, this is a good time to organise things better.

Transition

We will set up the configuration on the new web server to have two parts (at least): "legacy" and "new". The "legacy" configuration will consist of all those pages which will remain on the current web server (pp3). The (shiny) "new" configuration will consist of more organised web pages on the new web server (which will have a head server and a number of tails; one of which will be the legacy server). In particular, we can transfer sub-site by sub-site according to when the relevant people are free to do the work. (In order to prevent this becoming "forever" we must agree that "pp3" will not survive beyond the life of the machine that it is on!)

New Server Organisation

The new configuration will need to be discussed (a lot!) before and during its implementation. Primarily, I would like the management of this server to be divided according to the following classes:

1. Server Configuration.
2. Server Organisation.
3. Web page styles.
4. Web page content.

Orthogonal to this classification, I would like to see a division according to the following criteria (in brackets we have further possible divisions):

A. IMSc (semi-) static web pages (Main, Phys, TCS, Math, CC, Office, Library). B. IMSc dynamic content web site (Webmail, Calendar, Annual Report, Applications, IMSc E-print server). C. Personal Web pages (~user) D. Hosted Web sites. (whepp.org, iarcs, rms, ...) E. Personal Web sites (a new feature which is possible).

It will be organisationally very simple if each of the services A, B, C, D, E will be managed on separate (one or more) software servers which will function entirely independently.

The "head" server may just be a content-less proxy server (server 0) that remains visible on the internet as it currently is at www.imsc.res.in.

In the discussion below I want to concentrate on (aA), (bA) and (aC). If we continue to have a separate "head" server then the discussion applies to (a0) as well. To be absolutely clear, I am not discussing the style of the website or its content.

Version Control

Version control is a layer that is added on top of basic file editing that allows one to:

1. Keep track of why, when and by who the changes were made.
2. Allow for testing of the changes before they are made "live".
3. Quickly revert changes in case of bugs. In particular, recover accidental file deletions with older versions.
4. Keep "old tricks" in the system without keeping old files around for "reference".
5. Allow many people to work simultaneously on different parts of the system independently.

Of course, all this comes at a price --- people have to learn some commands and learn to use them in a certain way.

I would like to see (aA), (bA), (aC) and (a0) managed using version control. In particular, this means that we will do away with "live" editing of files for all these aspects of the web server.

Disk space and copies

Disk space is no longer at a premium so it is quite easy for each of the people involved in (aA), (bA), (aC) and (a0) to have a working copy of the relevant web service. All editing and testing can be done with this working copy. Once this is satisfactory, it can be "pushed" to the real web server with a "commit message" which will summarise the changes made.

Remaining Services

A number of the remaining services could also be managed similarly, but I would leave that option to the person responsible. The common repository system can be used for all these. The Web commitee may want to organise a seminar series on how to create and manage content for the web.