# Runtime JIT Proposals

- Thread: https://externals.io/message/27448
- Original archive: https://news-web.php.net/php.internals/27448
- Started by Sara Golemon on 2007-01-15T04:46:13+00:00
- Messages: 1
- 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

---

## #27448 — Sara Golemon — 2007-01-15T04:46:13+00:00

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

> Sorry but I wasn't on IRC so I don't quite
 > understand what you're trying to accomplish ;)
 > Can you please explain? Once I understand what
 > you're trying to accomplish I'll be more than
 > happy to provide feedback to the
 > options list.
 >
Oh, sorry, I thought you were in the email thread which preceeded the 
IRC discussion... Okay, I'll back up.


The root problem is HTTP input encoding detection for PHP6.  As you 
probably know, browsers don't tell webservers what encoding they're 
using, they just toss request data and hope the server knows how to deal 
with it.  PHP of course, has no idea what the script author has in mind 
for the purposes of their app so it has to resort to making "best 
guesses" which are sometimes accurate, sometimes not.

In order to boost the accuracy rate, we (Andrei, and others) thought 
it'd be a good idea to delay decoding of request parameters until during 
runtime (so that the user can perform some logic and perhaps offer a 
hint to the engine as to what encoding should be used).  To accomplish 
this, it made sense to us the JIT semantics of autoglobals as the mechanism.

This approach (which got some decent buyin from the list last month), 
means that the next steps get moved back by an action.  I.e. Before 
working up request encoding, we make JIT actually *be* JIT.  The 
approach we take to do this step is the subject of my earlier post.

Hope that helps clear things up.

-Sara