in reply to Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server

Assuming that the config files are not 'large' (eg Windows Registery-sized), would it not be better to have one .config for all the scripts, such that you have one config per virtual host? Obviously, you'd need to have XML or a similar layout on the config file, and new scripts should be able to add to the config file if they don't find defaults that they would expect.

-----------------------------------------------------
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

  • Comment on Re: Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server

Replies are listed 'Best First'.
Re: Re: Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server
by ajt (Prior) on Oct 02, 2001 at 18:18 UTC
    Masem I thought of that, I should have included it as an option (-- to me from my self).

    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