Actually, I said /etc, but thats a minor quibble. Template files are configuration files. Configuration files belong in /etc. Where '/' is really located is the more interesting question.

There are 3 primary web application layouts, and a flexible application can (and should) support them all. You've got the single-instance-on-a-single-OS layout. You've got the mass vhosting, or multiple-instances-on-a-single-OS layout. And you've got a no-privilege or per-user layout. Fundamentally the only thing thats different between these layouts is where the root of their filesystem is. In mass vhosting scenarious I've used / var/www/<host>, I've used /home/<host>, you get the idea--and the configuration files for that instance have always gone in <prefix>/etc/ <application> because thats where configuration files go, in etc. Individual users hosted off a single web server really isn't any different from multiple vhosts hosted off a single web server, except frequently the former could have more privilege (additional unix accounts) at it disposal than the latter.

The ownership of configuration files will vary between applications, but the simple principle to work by is that whomever is responsible for maintaining the application should have the ability to write to the files, and applciation process owner needs to be able to read them.

For example, lets look at two layouts of the same application on a Debian server.

Given: Application "foo", in a single- instance-on-a-single-OS layout, where foo needs two configuration files "database.cfg" and "lookyfeely.cfg". Web server process runs as "www-data:www-data". The maintainer is "bob:bob". database.cfg has sensitive info in it.

consider:

$ ls -al /etc/foo
total 6
drwxr-xr-x   3 root   root     1024 2004- 02-09 15:21 .
drwxr-xr-x  66 root   root     4096 2004- 02-09 15:21 ..
-rw-r-----   1 bob    www-data    24 2000-05-28 06:59 database.cfg
-rw-r--r--   1 bob    bob      122 2004- 01-05 23:13 lookyfeely.cfg
[download]

Thats not a bad solution, the web server process can read database.cfg, bob can edit both files, and lookyfeely is readable by everybody, it contains no sensitive information so hiding its contents from the other system users is unneccesary and www-data needs to be able to read it anyway. This requires super- user privileges to configure initially, but thats OK on a single- instance-on-a-single-OS, thats how it should be.

Now lets look at, moving to a per-user layout.

Given: Application "foo", in a per-user layout, where foo needs two configuration files "database.cfg" and "lookyfeely.cfg". Web server process runs as "www-data:www-data". The maintainer is "alice:alice". database.cfg has sensitive info in it.

consider:

$ ls -alR /home/alice
/home/alice:
total 13
drwxr-xr-x   3 alice   alice     1024 2004- 02-09 15:21 .
drwxr-xr-x   6 root   root     4096 2004- 02-09 15:21 ..
drwxr-xr-x   6 alice   alice     1024 2004- 02-09 15:21 etc
drwxr-xr-x   3 alice   alice     1024 2004- 02-09 15:21 public_html

/home/alice/etc:
total 6
drwxr-xr-x   3 alice   alice     1024 2004- 02-09 15:21 .
drwxr-xr-x   6 root   root     4096 2004- 02-09 15:21 ..
-rw-r--r--   1 alice   alice      24 2000- 05-28 06:59 database.cfg
-rw-r--r--   1 alice   alice     122 2004- 01-05 23:13 lookyfeely.cfg

/home/alice/public_html:
...
[download]

Now we run into a problem because any other system user can read alice's database configuration file, and thats bad if the other system users aren't trusted. But there isn't let the web server read the configuration it needs to if alice doesn't have any additional privileges. This leaves you with a lot of options which I'm not going to delve deeply into except to say: more groups, setfacl, Apache's suexec, or any number of other hacks will work around this issue. Its not the applications job to dictate which method should be chosen, but if possible it shouldn't stand in the way of any of them.

Back to the meat of original issue, the web server does not ever need to serve configuration files. Ever. Doing so is adding needless complexity to a fragile system. So allow me to refute your 3 points on when its a good idea, because I assert it is never a good idea:

1) The application is, or instances thereof are, ment to be installed by users with no special privileges.

Then either the application must never store sensitive information, or the web server must be configured to use a tool like suexec so the CGI scripts run as that user. Either way, as templates normally don't contain sensitive information this is moot, and its still not a good reason to leave them in a publishable directory, the CGI application can just as easily specify an include path and pull the templates from a directory in the users control that isn't publishable by the web server.

2) The overhead for a different solution (e.g. precompiled templates in a database) isn't worth it.

meh--the filesystem is a database, you wouldn't put data that had nothing in common into the same table of a RDBMS, why do it in a filesystem?
-or-
meh--the filesystem is a namespace, you wouldn't put methods that had nothing in common in the same API, why do it in a filesystem?

3) The application is designed to run multiple instances, each potentially with different templates.

Every instance should have its own configuration directory. The reality is that when this is the case there's a very good chance that you're going to need configuration data for other applications belonging to the instance as well, best plan for it ahead of time.

Edited by Chady -- fixed formatting.