On 01/22/2014 01:09 AM, Anatol Belski wrote:
On Wed, January 22, 2014 09:20, Anatol Belski wrote:
Hi,
as the discussion phase for this RFC nears to the finish and the patch
itself is huge, I'd like to use the last chance to discuss the open
questions and concerns. Here are once more the links to the RFC (with
several updates) and the porting guide
https://wiki.php.net/rfc/size_t_and_int64
http://git.php.net/?p=php-src.git;a=blob;f=compat/PECL_PORTING;hb=refs/hea
ds/str_size_and_int64
The big open question from the previous discussion is how to handle
changed ZPP formats. The way I've suggested in the porting doc is using
ternary operator like (COMP ? "l" : "i"). Another way were to put the old
ZPP formats "lLsp" back and make them redundant to the new ones "iISP".
Both ways have their pro and contra, the second variant isn't done, but
can be done quickly.
Also one big question from the RFC which haven't been addressed is the
handling of the stale SAPIs. While porting it turned out, that more than
50% of SAPIs reference no more actively supported web servers, some of
them are even not available anymore, no packages in the current
distributions seem to exist, no chance to check if they even complaint
with PHP mainstream. The SAPIs ported so far - apache2handler, CGI, CLI,
embed, FPM, phpdbg.
Please respond also if you have any other concerns about this RFC.
The voting phase is likely to be started on Sunday, January 22.
Sunday, January 26 - that's correct :)
Regards
Anatol
Hi Anatol,
This is a huge patch - kudos. However it will cause some short term
instability. It's the kind of deep change that typically would be
merged at the beginning, not the end, of a release process.
The new code will require time to stabilize. For example, there are
some new OCI8 diffs that will require debugging. There is one OCI8
code block in PHP-5.6 that isn't in the str_size_and_int64 branch.
(I'll send details separately). It's likely other extensions will be
similarly subtly impacted.
The open issues (e.g. SAPI support) need to be resolved before
starting the vote, so the RFC direction is obvious. Also the RFC
needs to discuss proposed voting options, prior to starting the vote.
Since that only gives a couple of days for discussion, I think you
should delay the vote.
The porting doc compat/PECL_PORTING should be merged into the RFC (and
removed from the tree) to capture as much information in the one place
as possible.
Chris
--
[email protected] http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html