# PHP 5.1

- Thread: https://externals.io/message/14469
- Original archive: https://news-web.php.net/php.internals/14469
- Started by Andi Gutmans on 2005-02-01T19:26:15+00:00
- Messages: 65
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/14469.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #14469 — Andi Gutmans — 2005-02-01T19:26:15+00:00

URL: https://externals.io/message/14469#14469

Hey,

I just heard from Wez that PDO is in very advanced stages now (ready for beta).
I would like to start the PHP 5.1 release process. Due to the lack of 
testing both the new engine VM and PDO have received I would like to start 
with a beta process so that we get feedback.

I know there are still some fixes that need to be applied both in the 
engine and in extensions so I would like to release a beta on March 1st (a 
month from today).
Derick also mentioned that his new very much needed Date 
extension will be ready by that date.

I believe both PDO and Date should be included in the default distro. As 
far as PDO is concerned I think for each DB if it is selected at configure 
time, the relevant PDO extension should also be enabled. So doing 
--with-oci8 should enable both ext/oci8 and ext/pdo_oci. This will give 
users more of a choice, give more exposure to PDO which is one of the most 
important features of 5.1 and of course, it doesn't really cost us very 
much except for having to do some configure hacking.

Comments/Flames/Praises to this list :)

Andi

---

## #14470 — Marc Richards — 2005-02-01T19:58:59+00:00

URL: https://externals.io/message/14469#14470 · In reply to: #14469

Andi Gutmans wrote:
> 
> Comments/Flames/Praises to this list :)
> 

All praise PHP 5.1.  All praise PDO.


Marc

---

## #14471 — Stephan Schmidt — 2005-02-01T20:20:40+00:00

URL: https://externals.io/message/14469#14471 · In reply to: #14469

Hi,

Andi Gutmans schrieb:
> I believe both PDO and Date should be included in the default distro.
I'd like to see xmlreader be bundled as well. It's fast, easy to use and 
still very powerful.

Stephan
-- 
http://www.php-tools.net
http://www.schst.net
http://pear.php.net

---

## #14472 — George Schlossnagle — 2005-02-01T20:23:51+00:00

URL: https://externals.io/message/14469#14472 · In reply to: #14471

> Hi,
>
> Andi Gutmans schrieb:
> > […]
> I'd like to see xmlreader be bundled as well. It's fast, easy to use 
> and still very powerful.

+1

George

---

## #14473 — Andi Gutmans — 2005-02-01T20:48:25+00:00

URL: https://externals.io/message/14469#14473 · In reply to: #14469

Don't see a problem with that if it's release quality.

Andi

At 09:20 PM 2/1/2005 +0100, Stephan Schmidt wrote:
>Hi,
>
>Andi Gutmans schrieb:
> > […]
>I'd like to see xmlreader be bundled as well. It's fast, easy to use and 
>still very powerful.
>
>Stephan
>--
>http://www.php-tools.net
>http://www.schst.net
>http://pear.php.net

---

## #14474 — Rasmus Lerdorf — 2005-02-01T22:10:54+00:00

URL: https://externals.io/message/14469#14474 · In reply to: #14469

Andi Gutmans wrote:
> I believe both PDO and Date should be included in the default distro. As 
> far as PDO is concerned I think for each DB if it is selected at 
> configure time, the relevant PDO extension should also be enabled. So 
> doing --with-oci8 should enable both ext/oci8 and ext/pdo_oci. This will 
> give users more of a choice, give more exposure to PDO which is one of 
> the most important features of 5.1 and of course, it doesn't really cost 
> us very much except for having to do some configure hacking.

If I can get off my ass and get it finished up it would be good to get a 
default input filtering extension in there as well.  We have not done 
much to help people do proper input validation and although the hook for 
it is in 5.0 I doubt anybody has actually used it yet.  I'll try to get 
it into PECL in the next week or so for people to have a look.

-Rasmus

---

## #14475 — l0t3k — 2005-02-01T22:21:06+00:00

URL: https://externals.io/message/14469#14475 · In reply to: #14469

Andi,
    i guess this means that proper serialization support for internal 
classes will have to wait till 5.2 ?

l0t3k

---

## #14476 — Andi Gutmans — 2005-02-01T22:29:02+00:00

URL: https://externals.io/message/14469#14476 · In reply to: #14469

As time is very short, I suggest to discuss exactly what we want and then 
to see if it's possible in a 5.1 time frame.
Can you give a short overview of what you had in mind and how the end-user 
would be using the functionality?

Thanks,
Andi

At 02:10 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:
>Andi Gutmans wrote:
> > […]
>
>If I can get off my ass and get it finished up it would be good to get a 
>default input filtering extension in there as well.  We have not done much 
>to help people do proper input validation and although the hook for it is 
>in 5.0 I doubt anybody has actually used it yet.  I'll try to get it into 
>PECL in the next week or so for people to have a look.
>
>-Rasmus

---

## #14477 — Andi Gutmans — 2005-02-01T22:36:42+00:00

URL: https://externals.io/message/14469#14477 · In reply to: #14469

When you mean support, basically it's just adding serialize/unserialize 
callbacks right? Doesn't mean all extensions need to implement them?


Andi

At 05:21 PM 2/1/2005 -0500, l0t3k wrote:
>Andi,
>     i guess this means that proper serialization support for internal
>classes will have to wait till 5.2 ?
>
>l0t3k

---

## #14478 — George Schlossnagle — 2005-02-01T22:37:52+00:00

URL: https://externals.io/message/14469#14478 · In reply to: #14477

> When you mean support, basically it's just adding 
> serialize/unserialize callbacks right? Doesn't mean all extensions 
> need to implement them?


Those can be 'bugfixes' in point releases?

George

---

## #14479 — Rasmus Lerdorf — 2005-02-01T22:41:39+00:00

URL: https://externals.io/message/14469#14479 · In reply to: #14476

Andi Gutmans wrote:
> As time is very short, I suggest to discuss exactly what we want and 
> then to see if it's possible in a 5.1 time frame.
> Can you give a short overview of what you had in mind and how the 
> end-user would be using the functionality?

Well, I am not starting from scratch here.  I have code, it just needs a 
bit of polishing.

But the general idea is to provide an optional filter that people can 
enable in their ini file.  This will strip out any XSS, quotes, braces, 
etc.  The actual list will need to be massaged a bit, and there will be 
multiple filters so people can choose how strict to be by default.

At the same time a filter access function is provided.

eg.

$age  = pfilter(POST, 'age', FILTER_DIGITS);
$addr = pfilter(POST, 'addr', FILTER_ALNUM);
$body = pfilter(REQUEST, 'body', FILTER_TAGS);
$raw  = pfilter(COOKIE,'cook', FILTER_RAW);

We obviously can't turn on the input filter by default, but even without 
the default filter enabled, providing a set of input filters for people 
to use so they don't have to come up with complicated regular 
expressions to check user input will go a long way to make it easier for 
people to write safer applications.  Even people who actually take the 
step to do input validation tend to get the validation wrong as we have 
seen in a number of recent examples.

-Rasmus

---

## #14482 — Christian Stocker — 2005-02-01T22:44:55+00:00

URL: https://externals.io/message/14469#14482 · In reply to: #14471

> Hi,
> 
> Andi Gutmans schrieb:
> 
> > […]
> 
> I'd like to see xmlreader be bundled as well. It's fast, easy to use and 
> still very powerful.

Very big +1 from me on that as well. XMLReader needs to be bundled, it's 
far superior to sax aka ext/xml and widespread use won't hurt (but 
that's just my 2 cents).

And Rob is working on better error reporting for the different XML 
classes. I have no ideas, how "finished" that is. But we need that in 
5.1, as well (I already told everyone, that 5.1 will have better error 
reporting ;) ). He can certainly better tell you, how far he is with that.

chregu

> 
> Stephan

-- 
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60  | fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB

---

## #14483 — Christian Schneider — 2005-02-01T23:11:31+00:00

URL: https://externals.io/message/14469#14483 · In reply to: #14479

Rasmus Lerdorf wrote:
> But the general idea is to provide an optional filter that people can 
> enable in their ini file.  This will strip out any XSS, quotes, braces, 

I assume this will include PHP functions to do the filtering as well? 
(Forgive me if we already have this now, I haven't looked at 5.0 enough 
yet :-))

> $age  = pfilter(POST, 'age', FILTER_DIGITS);
> $addr = pfilter(POST, 'addr', FILTER_ALNUM);
> $body = pfilter(REQUEST, 'body', FILTER_TAGS);
> $raw  = pfilter(COOKIE,'cook', FILTER_RAW);

Sounds like a good idea (even though the name pfilter reminds me too 
much of packet filter :-)). A catch-all could be handy too, e.g.
pfilter(REQUEST, DEFAULT, FILTER_TAGS);
which filters anything not handled before. Surely you can come up with a 
better interface but I hope you get the idea. Being able to define a 
default filter but still override it for certain variables is what I 
mean. (Also important would be that FILTER_TAGS is more robust than 
strip_tags which has some loopholes IIRC)

I agree that making input validation (or filtering) easy is important to 
help people write safer code. I once wrote a validator in PHP which 
allowed me to specify allowable tags including attributes and regular 
expression for the attribute values but it required the input to be 
XML/XHTML which might be a bit too harsh for most people.

A bit off-topic: I'm sure variable tainting has been discussed before, 
can some give the final opinion, was it found unsuitable/too much 
work/too inefficient or was it just post-poned (maybe indefinitely)?

- Chris

---

## #14484 — Rasmus Lerdorf — 2005-02-01T23:21:12+00:00

URL: https://externals.io/message/14469#14484 · In reply to: #14483

Christian Schneider wrote:
> Rasmus Lerdorf wrote:
> 
> > […]
> 
> 
> I assume this will include PHP functions to do the filtering as well? 
> (Forgive me if we already have this now, I haven't looked at 5.0 enough 
> yet :-))

Right,a function to filter user data through any of the filters will be 
provided as well.

> > […]
> 
> 
> Sounds like a good idea (even though the name pfilter reminds me too 
> much of packet filter :-)). A catch-all could be handy too, e.g.
> pfilter(REQUEST, DEFAULT, FILTER_TAGS);

I just made up the pfilter name.  I really don't care what it is called. 
  Figured filter() was a bit too generic and likely to step on existing 
user-space functions out there.


> which filters anything not handled before. Surely you can come up with a 
> better interface but I hope you get the idea. Being able to define a 
> default filter but still override it for certain variables is what I 
> mean. (Also important would be that FILTER_TAGS is more robust than 
> strip_tags which has some loopholes IIRC)

strip_tags only has loopholes if you allow some tags through.  But yes, 
this would be a very strict get rid of all tags filter and it needs to 
be charset aware.

> A bit off-topic: I'm sure variable tainting has been discussed before, 
> can some give the final opinion, was it found unsuitable/too much 
> work/too inefficient or was it just post-poned (maybe indefinitely)?

It is really hard to do this correctly.  Most user data in a web app is 
multi-purpose in the sense that it is often both displayed and inserted 
into a database, for example.  The untaint rules are vastly different 
for these two purposes.  Throw in a few more and you have a mess on your 
hands.  Just because you untainted it for one purpose doesn't mean it is 
safe for another, so I don't really see how a single taint flag can be 
all that effective.  I would rather see context-specific access function 
that retrieves the data for a specific purpose.  In this case 
implemented by calling pfilter with a given filter.

And just to clarify, since I added the hook to do this long ago, there 
aren't actually any PHP changes needed.  It can be completely handled in 
a pecl extension.  It just becomes a matter of whether/when to include 
it with PHP.

-Rasmus

---

## #14489 — Jochem Maas — 2005-02-02T00:31:02+00:00

URL: https://externals.io/message/14469#14489 · In reply to: #14483

> > […]
> 
> 
> Sounds like a good idea (even though the name pfilter reminds me too 
> much of packet filter :-)). A catch-all could be handy too, e.g.
> pfilter(REQUEST, DEFAULT, FILTER_TAGS);

maybe rfilter() - as in 'request filter'?

---

## #14494 — Jay Smith — 2005-02-02T00:51:56+00:00

URL: https://externals.io/message/14469#14494 · In reply to: #14469

Andi Gutmans wrote:

> Hey,
> 
> I just heard from Wez that PDO is in very advanced stages now (ready for
> beta). I would like to start the PHP 5.1 release process. Due to the lack
> of testing both the new engine VM and PDO have received I would like to
> start with a beta process so that we get feedback.
> 
> I know there are still some fixes that need to be applied both in the
> engine and in extensions so I would like to release a beta on March 1st (a
> month from today).
> Derick also mentioned that his new very much needed Date
> extension will be ready by that date.
> 
> I believe both PDO and Date should be included in the default distro. As
> far as PDO is concerned I think for each DB if it is selected at configure
> time, the relevant PDO extension should also be enabled. So doing
> --with-oci8 should enable both ext/oci8 and ext/pdo_oci. This will give
> users more of a choice, give more exposure to PDO which is one of the most
> important features of 5.1 and of course, it doesn't really cost us very
> much except for having to do some configure hacking.
> 
> Comments/Flames/Praises to this list :)
> 
> Andi

Seems every time I get ready to finally commit the new browscap stuff that
I've been sitting on for 5.1 since forever, something always comes up and
it gets on the backburner.

Since I've been out of the loop for so long (still passively reading the
lists, but I haven't had much time to actively participate in much of
anything of late) perhaps someone else should commit this stuff. There are
a few added files and a patch and that's pretty much it. I've tested
against a copy of HEAD I just checked out on linux and Win2k with VS6, and
it seems to work okay, although I haven't tried any of the Visual Studio
workspaces or anything, so they may assplode, I don't know.

The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
It's not exactly new VM exciting or PDO exciting (which, if you're reading
this Wez, looks quite nice), but browser detection is something I think PHP
should do well. It is primarily a web scripting language, after all. 

J

---

## #14501 — Andi Gutmans — 2005-02-02T01:06:03+00:00

URL: https://externals.io/message/14469#14501 · In reply to: #14469

Any volunteers to review and commit this?

At 07:51 PM 2/1/2005 -0500, Jay Smith wrote:
>Seems every time I get ready to finally commit the new browscap stuff that
>I've been sitting on for 5.1 since forever, something always comes up and
>it gets on the backburner.
>
>Since I've been out of the loop for so long (still passively reading the
>lists, but I haven't had much time to actively participate in much of
>anything of late) perhaps someone else should commit this stuff. There are
>a few added files and a patch and that's pretty much it. I've tested
>against a copy of HEAD I just checked out on linux and Win2k with VS6, and
>it seems to work okay, although I haven't tried any of the Visual Studio
>workspaces or anything, so they may assplode, I don't know.
>
>The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
>It's not exactly new VM exciting or PDO exciting (which, if you're reading
>this Wez, looks quite nice), but browser detection is something I think PHP
>should do well. It is primarily a web scripting language, after all.

---

## #14503 — Gareth Ardron — 2005-02-02T02:12:02+00:00

URL: https://externals.io/message/14469#14503 · In reply to: #14494

Jay Smith wrote:

>
>The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
>It's not exactly new VM exciting or PDO exciting (which, if you're reading
>this Wez, looks quite nice), but browser detection is something I think PHP
>should do well. It is primarily a web scripting language, after all. 
>  
>
Personally, anything that means I can remove the odd bit of shonky 
javascript would be welcome.

---

## #14505 — Ilia Alshanetsky — 2005-02-02T03:10:21+00:00

URL: https://externals.io/message/14469#14505 · In reply to: #14494

Jay,

I've noticed that you're still using the ini parser in this new code, 
would it not be easier and allow for greater code re-use to use the CSV 
database and the underlying fgetcsv code?

Ilia

Jay Smith wrote:
> Andi Gutmans wrote:
> 
> 
> > […]
> 
> 
> Seems every time I get ready to finally commit the new browscap stuff that
> I've been sitting on for 5.1 since forever, something always comes up and
> it gets on the backburner.
> 
> Since I've been out of the loop for so long (still passively reading the
> lists, but I haven't had much time to actively participate in much of
> anything of late) perhaps someone else should commit this stuff. There are
> a few added files and a patch and that's pretty much it. I've tested
> against a copy of HEAD I just checked out on linux and Win2k with VS6, and
> it seems to work okay, although I haven't tried any of the Visual Studio
> workspaces or anything, so they may assplode, I don't know.
> 
> The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
> It's not exactly new VM exciting or PDO exciting (which, if you're reading
> this Wez, looks quite nice), but browser detection is something I think PHP
> should do well. It is primarily a web scripting language, after all. 
> 
> J

---

## #14515 — Xuefer Tinys — 2005-02-02T05:50:30+00:00

URL: https://externals.io/message/14469#14515

more choices:
foo_bar(string $key or array $keys, int or string $how)
bar can be one of get,post,request,env,server
foo may be filter? ifilter? (i for input)

may foo be empty? _get _post etc..
$how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
for raw data same as $_GET['abc'] before. it's just simple
and it would make user easy to migrate their thinking, not just the script
we had made too much changes: $abc -> $HTTP_GET_VARS['abc'] ->
$_GET['abc'] -> _GET('abc') or filter_xxx(GET...)


> 
> 
> > […]
> 
> Wouldn't this make it more difficult to be extended by a user. The way
> I imagine it working now is like this:
> 
> function my_filter ()
> {
>        //blah blah
> }
> 
> define('FOO_MY_FILTER', 'myfilter');
> 
> foo_filter(FOO_POST, 'bar', FOO_MY_FILTER);
> 
> Then the constant really just becomes a callback and I can add anything
> in that I want.
> 
> Maybe?
> 
> -ryan
> 
> --
> http://theryanking.com/blog

---

## #14518 — Rasmus Lerdorf — 2005-02-02T07:26:05+00:00

URL: https://externals.io/message/14469#14518 · In reply to: #14515

Xuefer Tinys wrote:
> more choices:
> foo_bar(string $key or array $keys, int or string $how)
> bar can be one of get,post,request,env,server
> foo may be filter? ifilter? (i for input)
> 
> may foo be empty? _get _post etc..
> $how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
> for raw data same as $_GET['abc'] before. it's just simple
> and it would make user easy to migrate their thinking, not just the script
> we had made too much changes: $abc -> $HTTP_GET_VARS['abc'] ->
> $_GET['abc'] -> _GET('abc') or filter_xxx(GET...)

I don't think you understand.  The idea here is not to change anything. 
  Changing to _GET('abc') with a default raw filter would be completely 
pointless.

People would still be using $_GET['abc'] just like before.  If, and only 
if a default filter is in place in the ini file, then this value is 
filtered.  Depending on the filter this just means that the app will run 
exactly like before, except tags would be stripped, for example.

If no default filter is in place, which would be the most common case as 
it wouldn't be turned on by default, then this extension in no way 
affects existing code.  In this case all it provides are a set of easy 
to use data filtering functions that an application can make use of 
instead of trying to dream up regular expressions to handle all the 
various cases.  I think we have seen over the past couple of years that 
this is a very hard problem for developers to tackle in each and every 
PHP application and the whole point of PHP is to tackle these hard 
problems and provide an easy solution.

Anyway, I'll try to get some code into CVS this weekend and you guys can 
have a look.

-Rasmus

---

## #14524 — Jay Smith — 2005-02-02T15:31:37+00:00

URL: https://externals.io/message/14469#14524 · In reply to: #14505

Ilia Alshanetsky wrote:

> Jay,
> 
> I've noticed that you're still using the ini parser in this new code,
> would it not be easier and allow for greater code re-use to use the CSV
> database and the underlying fgetcsv code?
> 
> Ilia
> 

Hi Ilia, long time no irc...

It probably would be a lot easier to go with the CSV parser as far as code
maintenance is concerned, but I think the wtf factor may make it more
annoying than it's worth. I can already picture bug reports saying "my
browscap.ini file isn't being read any more, what gives". I'm sure it would
be no where close to as bad as register_globals, but still, it's some
unnecessary BC breakage that will probably be more trouble than it's worth.

This is a x.1 release, so I guess this would be the time to do a semi-major
change like this, but I personally don't think it's warranted from the
users perspective. Just an unnecessary (albeit quite minor) hurdle to
upgrading to 5.1, imho.

J

---

## #14531 — Jeff Moore — 2005-02-02T20:35:21+00:00

URL: https://externals.io/message/14469#14531 · In reply to: #14479

> But the general idea is to provide an optional filter that people can 
> enable in their ini file.  This will strip out any XSS, quotes, 
> braces, etc.

I hate to see more ini options.  They make it more difficult to write 
programs that work under a variety of configurations and more difficult 
to integrate programs written for different configurations.  I would 
like to less ini file variability in the wild, not more.

It seems to me like only the application knows what is valid data.  
Trying to bolt on input checking to existing applications from the 
outside looks like it would just break applications, perhaps in subtle 
and difficult to detect ways.

One example would be that applications which display back form values 
upon validation failure would be sending back modified values.  This 
can be disconcerting to the user.  The user may not even notice that 
what they typed was silently modified to be something else.

Doing this from the ini file just seems like another kind of 
magic_quotes_gpc to me.  I am not a fan of magic.

If ini file based filtering causes too many problems to turn on in 
general, then what good is having it?  If ini file based filtering 
becomes too specific to an individual application, then why not just 
let the application handle it?  It seems like a fine line to walk.

I am wary of an ini file based input filtering.

> echo filter(GET,'foo',FILTER_NUMBER);

A set of easy to use and easy to find whitelist oriented filtering and 
validation functions is a great idea.

Eventually, someone is going to want to start adding parameters to 
control the filtering.  This would be easier with individual functions 
for individual types.  Also, the filters would be more useful if they 
were de-coupled from the input mechanism.

What about:

echo filter_number($_GET['foo']);
echo filter_string($str);  // Perhaps same thing as strip_tags with no 
$allowed_tags, but white list oriented naming.
echo filter_html($str, $allowed_tags_and_attributes);  // improved 
strip_tags
etc.

Also perhaps something like this for registering input filters:

register_filter(GET, ALL, 'trim');
register_filter(GET, 'foo', 'filter_number');
register_filter(GET, 'bar', 'filter_html', 
$allowed_tags_and_attributes);

echo $_GET['foo'];
echo $_GET['bar'];

If there had to be a ini file option, then perhaps something taint-like:

block_unfiltered_input = 1

With this option, superglobals that didn't have filters registered 
would simply be NULL.  An option like this has to be able to be 
modified at runtime.  something like:

echo $_GET['foo'];   //   'bar'
ini_set('block_unfiltered_input', TRUE);
echo $_GET['foo'];  // `NULL` 

I have no idea how super globals are implemented, so I don't know if 
this is even possible.  These are just some additional ideas.

---

## #14532 — Rasmus Lerdorf — 2005-02-02T20:53:13+00:00

URL: https://externals.io/message/14469#14532 · In reply to: #14531

Jeff Moore wrote:
> 
> 
> 
> > […]
> 
> 
> I hate to see more ini options.  They make it more difficult to write 
> programs that work under a variety of configurations and more difficult 
> to integrate programs written for different configurations.  I would 
> like to less ini file variability in the wild, not more.
> 
> It seems to me like only the application knows what is valid data.  
> Trying to bolt on input checking to existing applications from the 
> outside looks like it would just break applications, perhaps in subtle 
> and difficult to detect ways.

We have seen definitively that many application writers do not know how 
to properly validate data.  And yes, it is another ini thing to worry 
about, and yes it will be painful, but I don't think we can continue to 
ignore this.  I also think that people who actually write good and 
secure web apps in PHP won't have too many problems with this.  It will 
just be an additional tool they can use if it is available.  For people 
who don't know what they are doing or don't care about security, it may 
very well break their applications, but those applications most likely 
should be broken.

Pick 10 random PHP apps out there and go through them.  With very very 
few exceptions 10 out of 10 will be insecure.  And the blame here is not 
just on the developers of those applications, we are partially to blame 
for not providing enough tools and guidelines.  This is what I am trying 
to rectify with minimum impact to the existing code and the way people 
do things.  Some of your suggestions are good, but some just aren't 
feasible.  For example, it would be difficult to implement your idea of 
only letting data through if a filter was assigned to it and having 
those filter assignments happen in the scripts themselves since that is 
too late in the game.  It could be hacked, but it would be ugly and 
complex.  Having just a single optional default filter per request is 
simpler to manage and implement.

-Rasmus

---

## #14535 — Marcus Boerger — 2005-02-02T21:26:15+00:00

URL: https://externals.io/message/14469#14535 · In reply to: #14469

Hello Andi,

Tuesday, February 1, 2005, 8:26:15 PM, you wrote:

> Hey,

> I just heard from Wez that PDO is in very advanced stages now (ready for beta).
> I would like to start the PHP 5.1 release process. Due to the lack of 
> testing both the new engine VM and PDO have received I would like to start
> with a beta process so that we get feedback.

I hope i can do my outstanding PDO work during the next few weeks so
the time frame is ok for me too.

However i'd like to see the 'ifsetor' or '?:' operator since it makes
many things much faster and easier to read.

Last but not least i have some forach-engine cleanup lingering around
which i will commit in the next days.

-- 
Best regards,
 Marcus                            mailto:helly@php.net

---

Next page: https://externals.io/message/14469.md?page=2