[Jani Taskinen [EMAIL PROTECTED]]
(could we have some nice 'codenames' for the releases? Please.. :)
Hey, what if we name them after the third noun on page five of your
(finnish) morning paper at the day of RC1 (using GMT)? :-)
- Stig
--
Stig Sther Bakken [EMAIL PROTECTED]
Fast Search
Quoting Hartmut Holzgraefe [EMAIL PROTECTED]:
arg_separator.output should default to 'nbsp;'.
nbsp; ??? i guess it will break lots ;)
maybe we should amp; instead?
Wow. Yeah, I'm really tired this morning. amp; is what I meant, of course...
Thanks, Hartmut. :)
-chuck
--
Charles
On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
Why do you see it as a problem? They should be doing their own
releases after our releases. ie. They should say that this version
works with PHP 4.0.5. People should know that when they get
the bleeding edge..it might not work at all.. There have
At 06:55 4/4/2001, Alexander Bokovoy wrote:
If so, why this change didn't find its way into PHP_4_0_5 branch? It was
done a week ago, at the time of ~ RC3 I think.
Because changes such as this aren't critical, make break things, and thus
do not belong in RCs.
Zeev
--
PHP Development Mailing
Quoting Joey Smith [EMAIL PROTECTED]:
I've never bought into this argument, because these companies
can include a "config.php", or something like that, which uses
ini_set() to set up the INI file however they need it...
But commercial companies aside, the plethora of configuration
But commercial companies aside, the plethora of configuration options
(like
magic_quotes_gpc) can and does make life harder for people writing code
libraries (like PEAR) that are meant to be dropped in anywhere, or for
people
trying to write applications that have minimal setup required, or
At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote:
But commercial companies aside, the plethora of configuration options
(like
magic_quotes_gpc) can and does make life harder for people writing code
libraries (like PEAR) that are meant to be dropped in anywhere, or for
people
trying to
There was a discussion about things to break in 4.1. magic_quotes_gpc would
definitely be my favourite. I'd like to see it set to off for good and
removed from php.ini.
I'd be completely against removing the concept of magic_quotes altogether.
We can discuss changing the default, but for
From: "Rasmus Lerdorf" [EMAIL PROTECTED]
Sent: Wednesday, April 04, 2001 7:22 PM
There was a discussion about things to break in 4.1. magic_quotes_gpc
would
definitely be my favourite. I'd like to see it set to off for good and
removed from php.ini.
I'd be completely against removing
Agreed that it's handy and easy, but it's a two-edged sword. If you write
scripts that should be distributed on many different servers, it takes a lot
of code to account for both settings.
I'm one of those control freaks ;) that like to be in total charge about
what data goes in and out of
hi,
There was a discussion about things to break in 4.1. magic_quotes_gpc
would
definitely be my favourite. I'd like to see it set to off for good and
removed from php.ini.
I'd be completely against removing the concept of magic_quotes altogether.
We can discuss changing the default,
On Thu, 5 Apr 2001, Boian Bonev wrote:
count of boxes broken if arg_separator is ';'
count of boxes that dont care about arg_separator default
count of boxes that need arg_separator to be ';'
count of boxes relying on magic_quotes_gpc
count of boxes that dont care about magic_quotes_gpc
count of
I disagree, we explicitly document that the arg_separator defaults to
and that this is the character that separates url arguments. This follows
the original CGI specification. The fact that this is no longer the
accepted standard for this doesn't mean we can just up and change it in a
minor
I disagree, we explicitly document that the arg_separator defaults to
and that this is the character that separates url arguments. This follows
the original CGI specification. The fact that this is no longer the
accepted standard for this doesn't mean we can just up and change it in a
Just to reply to myself we are fairly broken here according to rfc 2396 but
if you guys think thats acceptable until 4.1 (whenever that might be) then
thats fine..
Relavant part of RFC:
2.2. Reserved Characters
Many URI include components consisting of or delimited by, certain
special
On Tue, 3 Apr 2001, Rasmus Lerdorf wrote:
I disagree, we explicitly document that the arg_separator defaults to
and that this is the character that separates url arguments. This follows
the original CGI specification. The fact that this is no longer the
accepted standard for this doesn't mean
Just thinking out loud here before I go to bed...how about:
arg_sep.read = "" | ";"
arg_sep.write = ";"
Or something like this. It'd be nice to be able to do the |.
On Tue, 3 Apr 2001, James Moore wrote the following to Rasmus Lerdorf and...:
I disagree, we explicitly document that the
Which reminds me: If arg_separator is used like it was before my patch
and you set it to e.g. ';' and then have a form which method
is GET..well, it won't work. there would be one variable
holding all the info.
Urls that are the result of a submitted form are generated by the browser
and not
On Tue, 3 Apr 2001, Edin Kadribasic wrote:
Which reminds me: If arg_separator is used like it was before my patch
and you set it to e.g. ';' and then have a form which method
is GET..well, it won't work. there would be one variable
holding all the info.
Urls that are the result of a
Which reminds me: If arg_separator is used like it was before my patch
and you set it to e.g. ';' and then have a form which method
is GET..well, it won't work. there would be one variable
holding all the info.
Urls that are the result of a submitted form are generated by the browser
PROTECTED]; PHP Quality Assurance
[EMAIL PROTECTED]
Sent: Wednesday, April 04, 2001 12:14 AM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Which reminds me: If arg_separator is used like it was before my
patch
and you set it to e.g. ';' and then have a form which
On Tue, Apr 03, 2001 at 03:18:00PM -0600, Joey Smith wrote:
Speaking of this, I think we need to collect all of these types of
issues that are waiting for a "4.1" release somewhere, so we can get a
clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If
not, I can go search the
On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
There is one problem which could come dangerous for extensions in
future: change made a week ago in configure macros: AC_ADD_* -
PHP_ADD_* This change was made in HEAD branch but PHP_4_0_5 wasn't
reflected. It means that external extensions (PHP-GTK,
On Wed, Apr 04, 2001 at 12:55:52AM +0200, Jani Taskinen wrote:
On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
There is one problem which could come dangerous for extensions in
future: change made a week ago in configure macros: AC_ADD_* -
PHP_ADD_* This change was made in HEAD branch but
24 matches
Mail list logo
