Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74217 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27758 invoked from network); 15 May 2014 07:59:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2014 07:59:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:37680] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CB/81-14382-3F374735 for ; Thu, 15 May 2014 03:59:49 -0400 Received: (qmail 3926 invoked by uid 89); 15 May 2014 07:59:34 -0000 Received: by simscan 1.3.1 ppid: 3892, pid: 3910, t: 4.8035s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 15 May 2014 07:59:30 -0000 Message-ID: <53747494.2000807@lsces.co.uk> Date: Thu, 15 May 2014 09:02:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: PHP internals Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Support for all users? From: lester@lsces.co.uk (Lester Caine) Having now established that phpng only currently supports MySQL and SQLite, many of us are once again cut out of the loop. That the structural changes require a deep understanding of the 'new engine' to make the missing extensions available cuts out other people picking up the baton easily, so we are stuck with a half built alternative and no roadmap as to when it may be testable by everyone? The 32/64 bit discussion has a great relevance to interfaces like the database ones where these may already be supporting 64bit length strings, and the like, so coming up with an acceptable compromise on this is important. I STILL see 'unicode' in this jigsaw as maintaining 32bit length strings with a multibyte capability for those areas where in reality even a 16bit limit would be more appropriate? Can we please identify all of the elements that need to be addressed for PHPNext, rather than pushing votes on things which essentially combine a number of unrelated options. PHP still has to support 32bit lengths on 32bit platforms so 64bit strings have to co-exist with that. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk