Seriously, being able to include other ini files is a great feature,
especially for hosters who will then be able to set up site-wide config
files that are included from per-vhost config files, etc. You can have
your cake and eat it too.
Sure :).
A way to make this functionnality on others
IMHO, the enemy of the good is the better.
We can implement the binary-dir solution in no time, and it covers 95% of
the problems easily, but instead we'll be discussing perfect solutions and
end up doing nothing :)
My 2 agorot.
Zeev
At 08:03 03/05/2002, Markus Fischer wrote:
Hi,
At 07:51 03/05/2002, Stig S. Bakken wrote:
Edin and I were discussing ini files on IRC last night and the same idea
came up. With the exact same syntax too, actually. This is divine
proof that the include_ini is good and must be implemented. :-)
Seriously, being able to include other ini files
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
IMHO, the enemy of the good is the better.
We can implement the binary-dir solution in no time, and it covers 95% of
the problems easily, but instead we'll be discussing perfect solutions and
end up doing nothing :)
Yes, please! :)
Remember
Well, you are correct that the size of the executable is irrelevant, but
having different instances of PHP means less shared pages when multiple
copies are loaded. There is a definite advantage to having a single httpd
binary that is the same for everyone when it comes to runtime memory
usage.
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
Well, you are correct that the size of the executable is irrelevant, but
having different instances of PHP means less shared pages when multiple
copies are loaded. There is a definite advantage to having a single httpd
binary that is the same
This is true, there will be less shared pages. I *want* this!
(Though I was talking about PHP and not httpd).
Well, they are commonly one and the same. But I guess you are on a
Windows/CGI platform? This doesn't really apply there.
-Rasmus
--
PHP Development Mailing List
Well, you are correct that the size of the executable is irrelevant, but
having different instances of PHP means less shared pages when multiple
copies are loaded. There is a definite advantage to having a single httpd
binary that is the same for everyone when it comes to runtime memory
Zeev Suraski [EMAIL PROTECTED] wrote:
We could add it. I just hope people wouldn't start demanding control
structures in there to start selectively loading other files...
let's just hope that by then, someone realizes we already have a
scanner and parser that handles such a language close at
Pierre-Alain Joye wrote:
Seriously, being able to include other ini files is a great feature,
especially for hosters who will then be able to set up site-wide config
files that are included from per-vhost config files, etc. You can have
your cake and eat it too.
Sure :).
A way to make this
Joseph Tate wrote:
Well, you are correct that the size of the executable is irrelevant, but
having different instances of PHP means less shared pages when multiple
copies are loaded. There is a definite advantage to having a single httpd
binary that is the same for everyone when it comes to
There's no reason to not put in the bin-dir solution now. I just would
like to see an eventual full solution to the issue.
Zeev Suraski wrote:
IMHO, the enemy of the good is the better.
We can implement the binary-dir solution in no time, and it covers 95%
of the problems easily, but
Pierre-Alain Joye wrote:
Seriously, being able to include other ini files is a great feature,
especially for hosters who will then be able to set up site-wide config
files that are included from per-vhost config files, etc. You can have
your cake and eat it too.
Sure :).
A way to make
At 17:24 03/05/2002, Jim Winstead wrote:
Zeev Suraski [EMAIL PROTECTED] wrote:
We could add it. I just hope people wouldn't start demanding control
structures in there to start selectively loading other files...
let's just hope that by then, someone realizes we already have a
scanner and
Does anybody have an opinion about this?
If we go for that solution, should we remove the CWD lookup? My personal
belief is that we should, but it may have to do with my perception of what
this feature is useful for. Other people may be using the CWD lookup for
different things.
(Note: it's
On Thu, 2 May 2002, Zeev Suraski wrote:
Does anybody have an opinion about this?
If we go for that solution, should we remove the CWD lookup? My personal
belief is that we should, but it may have to do with my perception of what
this feature is useful for. Other people may be using the
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns for different
customers...
Do you know this for a fact, or is this an estimate?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns for different
customers...
Do you know this for a fact, or is this an estimate?
This is a fact, some hoster here in .nl uses it.
Derick
At the risk of getting toasted out of the water... do any serious hosters
use a Win32 enviroment to host on? (who would utilise this way of setting
different settings for different clients)
Are there any poll's we could reference against of PHP users (on Win32
enviroments) and what they use it
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns for different
customers...
Do you know this for a fact, or is this an estimate?
This is a fact,
We're not necessarily talking about Win32...
Zeev
At 14:02 02/05/2002, Dan Hardiker wrote:
At the risk of getting toasted out of the water... do any serious hosters
use a Win32 enviroment to host on? (who would utilise this way of setting
different settings for different clients)
Are there any
At the risk of getting toasted out of the water... do any serious hosters
use a Win32 enviroment to host on? (who would utilise this way of setting
different settings for different clients)
Intranet applications using (d)com, mssql run on win NT/2K.
Are there any poll's we could reference
On Thu, 2 May 2002, Zeev Suraski wrote:
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns for different
customers...
Do you know this for
I'm in favour of looking for php.ini in the same dir as the executeable
module - as in the path part of GetModuleFileName(), so it will work for
DLL as well as EXE versions.
I'm a bit dubious of using the registry for configuring PHP, particularly
when multiple installations/versions are
At 15:09 02/05/2002, [EMAIL PROTECTED] wrote:
Ok then, perhaps we should have an .ini setting for it? :)
So you want to add an .ini setting where the .ini file could be found?
That just doesn't make sense to me :)
That was a joke..
The only two options I see, in that case are:
- Add
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
At 15:09 02/05/2002, [EMAIL PROTECTED] wrote:
Ok then, perhaps we should have an .ini setting for it? :)
So you want to add an .ini setting where the .ini file could be found?
That just doesn't make sense to me :)
That was a joke..
At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns for different
customers...
Do you know this for a
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to have different settigns
Preston L. Bannister wrote:
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
Some hosters use this feature to
Isn't this all a bit of an overkill?
Andi
At 12:18 02/05/2002 -0700, Shane Caraveo wrote:
Zeev Suraski wrote:
Does anybody have an opinion about this?
Of course! ;)
ini search order
1. PHP_BIN_DIR (\php\)
2. OS_DIR (\winnt\)
To fix the ini issue we need more than just this. The best I can
At 13:14 02/05/2002 -0700, Shane Caraveo wrote:
Andi Gutmans wrote:
Isn't this all a bit of an overkill?
Andi
#5 probably is, it's a nicety, but I think the other items are relatively
necessary unless you are dependent entirely on Apache, which provides
extensive configurability.
#1
On Thu, 2 May 2002, Shane Caraveo wrote:
#4 is realy needed for systems running virtual servers under IIS. While
you can configure ini in the registry, it's a pain, especially if you
want to give users access to edit their own ini file, or you want
different extensions loaded for
Zeev Suraski wrote:
On Thu, 2 May 2002, Shane Caraveo wrote:
#4 is realy needed for systems running virtual servers under IIS. While
you can configure ini in the registry, it's a pain, especially if you
want to give users access to edit their own ini file, or you want
different
On Thu, 2002-05-02 at 19:07, Preston L. Bannister wrote:
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
On Thu, 2 May 2002, Zeev Suraski wrote:
At 13:36 02/05/2002, [EMAIL PROTECTED]
On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote:
Zeev Suraski wrote:
Does anybody have an opinion about this?
Of course! ;)
ini search order
1. PHP_BIN_DIR (\php\)
2. OS_DIR (\winnt\)
To fix the ini issue we need more than just this. The best I can come
up with right now is:
Hi,
but including other INI files at this stage is only of real
advantage if we can also conditionally include it, no? Like,
depending on the version too.
How about looking for the version number in the filename too
first, e.g.:
php-apache-4.2.1.ini
Daniel Beulshausen wrote:
At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
they should be changed to use the windows registry anyway...
Feel free to do it :)
this isn't going to be a big task, i'll put it onto my todo.
It's already done, been there for a long time. php.ini values
At 11:41 01.05.2002 -0700, Shane Caraveo wrote:
Daniel Beulshausen wrote:
At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
they should be changed to use the windows registry anyway...
Feel free to do it :)
this isn't going to be a big task, i'll put it onto my todo.
It's already done,
Daniel Beulshausen wrote:
At 11:41 01.05.2002 -0700, Shane Caraveo wrote:
Daniel Beulshausen wrote:
At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
they should be changed to use the windows registry anyway...
Feel free to do it :)
this isn't going to be a big task, i'll put it
At 23:11 01/05/2002, Shane Caraveo wrote:
That would only solve that particular situation, what about multiple
installations of the same version, or seperate configurations for the same
installation?
We can have PHP look for php.ini in the directory where php.exe is
located. This would allow
40 matches
Mail list logo
