Since there is no asp equivalent to php.ini, there is little likelyhood that an Imail installation that attempts to automatically set up a website in IIS could hose any configurations. It could simply check that IIS is installed and running, requiring only that the user add the IIS service beforehand. It could then install itself into a virtual directory off the default site, or allow you to set up a dedicated IIS site for it, all through wizards.
However, If Imail attempted to install PHP with its installer, it could hose an existing PHP install. If it doesn't install it, but instead requires you to install and configure PHP first, then it isn't a simple install anymore. Unlike IIS, you can't just install PHP and run with it, you MUST configure it via the PHP.ini first. And despite its voluminous comments, the php.ini can still be confusing to those not accustomed to web work. If Imail attempted to set up a site in Apache, it could DEFINITELY hose a thing or two on pre-existing installations. Installing IIS/ASP is a very simple process. Installing a new website into that IIS/ASP is also very simple and can be automated through the setup process with no danger to pre-existing configurations. Not so for Apache/PHP. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dev Sent: Monday, April 25, 2005 3:30 PM To: [email protected] Subject: Re[2]: [IMail Forum] Survery responses - PHP For years, Imail's raison d'�tre was their simple 10-minute install that would simply work out of the box with minimal effort. People here have correctly noted that if you try to blindly piggyback webmail onto an existing and already configured webserver, the Imail install risks accidentally hosing existing sites with potential catastrophic results. So how many ways are there to prevent that and still guarantee that webmail will work out of the box? An open-source-based webserver for Imail's exclusive use could and should be maintained primarily by regular Ipswitch patches and upgrades. Hypothetical: If a vulnerability is announced in Apache or PHP, Ipswitch should quickly release a patch for its webserver. If they don't, users know that Ipswitch has reverted back to its bad old ways. And users would STILL be able to update the vulnerable code. It keeps Ipswitch honest and responsive, and protects users against egregious unpatched security vulnerabilities. Sounds like a win/win to me. It's a darn sight better than what they have now--ancient obsolete code with unknown vulnerabilities, and no way for customers to do anything about it. We'll have to see what Ipswitch decides. Regardless of the direction they decide to pursue, I'm heartened that Ipswitch is at least asking the question and soliciting our feedback FIRST. It seems to me they have learned the important lesson from the ICS debacle. :-) Dev Monday, April 25, 2005, 11:46:33 AM, you wrote: M> Dev wrote: >>Ipswitch installer could setup a customized pre-configured open-source >>webserver INSIDE the IMAIL installation directory. This config would >>have no effect on any existing webserver installations. (Other than to >>make sure they are not listening on the same >>port.) >> M> It's thinking like this that got us to where we are now. M> Matt To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
