Derick has requested the ability to be able to specify an array
parameter instead of/as well as a string.
What I plan to implement is an additional (optional) filter operation
that is given an opportunity to pre-process the zval and make it
available to the underlying implementation.

> stream_filter_append($fp, "convert.quoted-printable-encode/base64-decode",
>       "base64-decode.ignore-eof=1,quoted-printable-encode.soft-line-break=1");

> stream_filter_append($fp, "convert",
>       "base64-encode:flush-on-close,forbid-seek/base64-decode:forbid-seek");
                                  ^^^^^^^^^^^
Streams API will spot a filtered stream and disallow seeking. (Except
for the emulated forward seek using read).

> Now what do you think of this? I need a decision.

The idea is that the filter name identifies a specific filter.
The parameters are used to tune specific aspects of the filter; such as
compression level, encryption keys and so-on.
So the former option is preferred...

As for the problem of choosing filters for the read/write streams, I
plan to introduce two separate read/write filter chains in PHP 5 and
allow the user to decide which filters to apply.

This needs to be comfortable for the user to pick and choose filters, so
it might require a modification to the user-space API, or perhaps the
introduction of a new function (latter is preferred).

> By the way, I find the converter is quite portable and also important
> for i18n stuff, I'd like to make the converter independent to
> the filter code. Any comments on this?

Having a core conversion system is a big plus (and will solve some of
the depenencies on mbstring issues we have for other extensions).

If the conversion system is abstracted nicely, it can provide a core set of
converters and allow other extensions (such as iconv, recode, mbstring)
to register other codesets (perhaps using a wildcard or some dynamic
query mechanism such as that used in the filters API) when they are
loaded at runtime.

If you do it this way, you get a +100 from me :-)

--Wez.


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to