Re: php6: input encoding, filter and making JIT really JIT

On 12/15/06, Andrei Zmievski <andrei@gravitonic.com> wrote:

On Dec 14, 2006, at 12:59 PM, Pierre wrote: The main disadvantages are: - the lack of flexibility, encoding must be set before the script gets the hand, using vhost config or htaccess - the possible bad encoding detection will force the user to manually parse the raw request (when available). Also: - no way to issue an error if conversion fails except by setting a flag that has to be retrieved with a function - much harder to get to _charset_ if it's at the end of the request * Init - don't parse the request but simply store it for later processing We can still parse the data, we just can't decode it. Parsing would populate arrays (internal or otherwise) with the binary data that can later be decoded and filtered in JIT fashion.

I like the lazy approach, if the data is not used, we do nothing.

There is no real technical disadvantages but requires more work and changes in the engine. But these changes will also bring some more performance improvements (if (0) $t = $_ENV['foo']; will not trigger jit). I guess we need to know how hard it would be to implement runtime JIT for GET/POST/COOKIE registration.

The infrastructure exists already. There is no difficulty to add get/post/cookie to the jit auto globals but to change how JIT works. We need to move it to runtime (fetch time), not hard but will need good tests :) --Pierre