Newsgroups: php.internals,php.pdo Path: news.php.net Xref: news.php.net php.internals:35105 php.pdo:93 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34144 invoked by uid 1010); 2 Feb 2008 17:06:22 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 34111 invoked from network); 2 Feb 2008 17:06:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2008 17:06:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=steph@zend.com; spf=permerror; sender-id=softfail Authentication-Results: pb1.pair.com header.from=steph@zend.com; sender-id=softfail Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.131 cause and error) X-PHP-List-Original-Sender: steph@zend.com X-Host-Fingerprint: 64.97.136.131 smtpout0131.sc1.he.tucows.com Solaris 8 (1) Received: from [64.97.136.131] ([64.97.136.131:28606] helo=n064.sc1.he.tucows.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/0D-41947-D03A4A74 for ; Sat, 02 Feb 2008 12:06:22 -0500 Received: from sc1-out08.emaildefenseservice.com (64.97.139.2) by n064.sc1.he.tucows.com (7.2.069.1) id 47697705008BB6C8; Sat, 2 Feb 2008 17:06:06 +0000 X-SpamScore: 2 X-Spamcatcher-Summary: 2,0,0,6b5fbf60950fa0bb,bf31a76f0721cb6f,steph@zend.com,-,RULES_HIT:2:355:379:539:540:541:542:543:567:599:600:601:945:960:967:973:980:988:989:1155:1156:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1587:1593:1594:1605:1606:1730:1747:1766:1792:2073:2075:2078:2194:2198:2199:2200:2393:2525:2551:2553:2559:2564:2682:2685:2828:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3421:3622:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936: 3938:3941:3944:4118:4250:4470:4886:5007:6119:6261:7576:7653:7679,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spamcatcher-Explanation: Received: from foxbox (62-31-252-198.cable.ubr07.shef.blueyonder.co.uk [62.31.252.198]) (Authenticated sender: steph.fox) by sc1-out08.emaildefenseservice.com (Postfix) with ESMTP; Sat, 2 Feb 2008 17:06:05 +0000 (UTC) Message-ID: <007201c865be$043430e0$c6fc1f3e@foxbox> Reply-To: "Steph Fox" To: "Marcus Boerger" , "Wez Furlong" Cc: , References: <37388396.20080201212653@marcus-boerger.de> <047101c8654b$11c7abb0$c6fc1f3e@foxbox> <07969D40-134A-41CE-ABEE-80C0BB9742A0@messagesystems.com> <24733767.20080202135024@marcus-boerger.de> Date: Sat, 2 Feb 2008 17:06:53 -0000 Organization: Zend Technologies MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2 From: steph@zend.com ("Steph Fox") Be fair, this is an open list. Anyone can join it, and it keeps the noise levels down on internals@. Please? ;) http://news.php.net/php.pdo - Steph ----- Original Message ----- From: "Marcus Boerger" To: "Wez Furlong" Cc: "Steph Fox" ; ; Sent: Saturday, February 02, 2008 12:50 PM Subject: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2 > Hello Wez, > > keeping the discussion on this list is a major mistake. And it is > actually > the reason why everyone outside this list is against it. And whether you > read blogs or not does not interest anybody at all - unless you are going > to > comment on every single blog that mentions PHP and CLA. So far PHP is open > source! Respect this please!! Open means open!!! > > I am crossposting to internals again. People should know what is going on. > Otherwise we could simply sign NDAs and be done. > > marcus > > Saturday, February 2, 2008, 6:36:17 AM, you wrote: > >> On Feb 1, 2008, at 10:24 PM, Steph Fox wrote: > >>> Wez, >>> >>> The only difference between my initial proposal, the one Ben Ramsey >>> posted and this one from Marcus is that they're getting more >>> complex, *without anyone actually discussing anything at all*. > >> On the contrary, there's been plenty of discussion going on. Despite >> my request that we keep the discussion on this list, people have been >> talking to each other in real life, on the phone, talking on IRC, IM, >> posting thoughts and comments to blogs and so forth. Some comments >> positive, some negative, but discussion nonetheless. > >> I've been making an effort to read the various blog entries, even >> those in foreign languages (thanks to a combination of blog searching >> tools and google translation tools) and keep an eye on IRC when I have >> a spare minute or two. > > >>> ... He had a response from Jay, who said this had already been >>> discussed. According to him, >>> >>> "There was some dissent among members about the core and the spec/ >>> API docs being non-CLA'd which is why the proposal is currently the >>> way it is. I know that various legal teams had concerns about PDO >>> core not being under CLA, but if a case is made in the community for >>> this, perhaps minds may change." >>> >>> Now you're saying there's no problem with this approach? Where's the >>> real discussion going on? > >> No, I didn't say that there's no problem, I said that this sounds >> reasonable. > >> For example, a problem with this general solution is still that >> database experts from multiple sources would not be able to directly >> co-operate on the PDO core. However, it sounds to me like a >> reasonable (though sub-optimal, from a technical and productivity >> point of view) compromise to be able to accept feedback and >> suggestions and have those gated through the PDO core maintainers. > >> That's just my opinion; I certainly don't speak for anyone else. > >>> It's not a bad thing per se to separate PECL and PHP, but it does >>> beg the question of how to approach distributions/snaps, which is >>> AFAICS the only reason anything not essential to PHP itself is in >>> the core in the first place. Nobody's sat down and worked it through >>> properly, despite Lukas' repeated requests. > >> One reason that no one has discussed that is because it is not >> directly related to the question of PDO and how to best get the >> vendors involved. Once we've figured that out, we can iron out the >> details of the implementation. > >>> I think if we did this it would have to be as part of a broader >>> approach, with a full re-evaluation of the PHP/PECL relationship, >>> some hard thinking about distribution mechanisms for PECL, and some >>> serious decisions about setup recommendations. It's really not the >>> quick fix it appears to be... and making it so without putting that >>> effort into it would hit the PHP userbase harder than anyone else. > >> And that's well beyond the scope of PDO. Remember, one of the >> concerns raised by the community was that this business would >> interfere with the rest of PHP; the suggestions we've made so far have >> been intentionally very focused to avoid getting into that. > >> Again; first let's see if we can find an acceptable way to take their >> contributions before moving on to those finer points. > >>> BTW I'm still waiting to hear about the other alternatives that were >>> discussed behind our backs, and the objections against them... and I >>> say 'behind our backs' simply because nobody seems to want to tell us! > >> We talked about whether the various vendors could work on various >> combinations of pieces of the code if they were or were not CLA'd. >> I'm sure you don't really need me to list the various combinations of >> CLA, not CLA, in PHP, in PECL, outside of PHP, and hosted individually >> by the vendors. It was not a very exciting discussion. > >> The main realization was that the vendors could not co-operate with >> each other on code without a CLA in place, and that some of them would >> not be able to co-operate with the community without a CLA in place. > >> --Wez. > > > > > Best regards, > Marcus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >