The problem with all in one file is that many scripts, STAMP included weren't designed for this, and you have to think with an extra level of nesting in the configuration stage. It's a good idea if you think about it first.

However, imaging the situtuation where you're trying to replace Selena Sol or MSA scripts on a hosting companies server. Now you have the problem that each user has to edit the global file, which I don't think is smart, unless you build a process for editing such a file (really should be a DB I suppose on this scale), so that they can change their own bits.

If you have multiple files, more sophisticated than my first stab, you can let users own and configure them on their own. Though now you have to be careful when you parse them....!

My case is a bit simpler, it's just a bunch of web sites for the same company, but in differnt domains on the same box (.de .co.uk etc), but I was wondering how you go about remplacing formmail et al on an under staffed hosting companies server.

As ever thanks in advance

Ok, here's another suggestion: make several levels of config files; one file at the global level, one per v.server at the server level, and possibly a third file local on the v.server's directory for local changes. The order that you'd search these is up to you; if none of the configuration settings are security related parameters, I'd first search user, then v.server, then global; otherwise, you could play around with flagging certain configuration variables that can only be set in the global or v.server files.

This would allow changing one config parameters across a site at one file, while also allowing the end user some ability to configure their site as well.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important