Mr. Dreadsoft wrote:

/some installing systems like NSIS can search for existing php-gtk 
installations. For example, a developer may have a "standard" php-gtk 
installation and another "alpha" installation for testing purposes.

btw, NSIS can use its own download functions (nsisdl.dll functions), so 
wget is not necessary. Anyhow, it would be interesting in a 
cross-platform installer.

/Did not know NSIS could download, even better! /
//
or a standard directory structure, at least for php, extensions, gtk.

/Yes & thats the point of using the registry, as long as the `standard 
current/stable` version path is in the registry then the user can still 
install where they want to, and the extensions etc will be in a 
standardized directory structure format.

All other info could be extracted from the php.ini or from php itself as 
pointed to in the registry.

..............................................................................

Adrian Snyman wrote:

/I have also been in a situation where a program is set up to work in a
SPECIFIC environment. Now I know that we could only certify the
program for a specific release of the underlying software, and the 
client was
forced to ensure their version did comply.
/

/
/

A standalone kit is preferred for many situations and multiple reasons, 
... I have my own for my own usage , however for general php-gtk2 
promotion would it not be nice to have a standardized system so you 
could package up small/whatever app's and know that they are going to 
work for all win32 users without having to package 10MB+ of stuff they 
may or may not already have ?

Also if we have some *published* standards/schema then when we/others do 
make standalone installations we know what to steer clear of to avoid 
messing with the standard installation (like how many apps put the 
php.ini or my.cnf/mysql dll's in %WINDIR% and break other installations) 
, avoiding all of that would give php-gtk2 on win32 some stability.

I just know that when designed by committee we will end up with c:/php5 
and c:/windows php.ini both of which (especially the latter) are bad 
news.. however this issue has popped up enough times already that 
perhaps its time to solve it ?

.................................................................................

I dont think x-platform should come into this particular argument.. 
linux is a whole different kettle of fish with bigger issues of 
dependencies/versions etc.. then again package management is not my thang ;)

Regards,
Simon.