Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Hello David, Wednesday, February 27, 2008, 9:27:16 PM, you wrote: Greetings, PDO community! My name is David Sceppa and I am a program manager working at Microsoft on improving SQL Server for PHP data hosting. Let me first just say that Microsoft is very interested in participating in the PDO 2 effort and I plan to actively engage in the discussions of the spec and the core via the mailing list. As a relative newcomer to this space, Microsoft is highly incented to see a single solution that serves the needs of this community. This is both from the standpoint of technical investment (i.e. we would like to focus our resources on delivering one rock solid answer rather than many across the space), and for customer clarity as having too many choices often winds up being confusing. We believe that PDO 2 is that solution going forward in the PHP space, and we are therefore committed to seeing it through to fruition. The approach that's been described in proposals (vendor-built drivers can be covered via CLAs while the core components remain CLA-free) is something I believe to be in the best interests of both driver writers and the developers who use PDO. We would prefer to have the spec and the core covered by CLA, so that we can make more direct contributions, yet we understand that the community wishes to keep the spec and the core CLA-free. Microsoft has a great deal of experience and lessons learned (both positive and negative) through the evolution of ODBC and other data access technologies that give us a unique perspective and we look forward to contributing to the PDO 2 effort. I look forward to diving into more technical discussions on the mailing list on issues such as whether or not there should be a set of core PDO libraries, the PDO metadata vocabulary, driver extensibility, etc. Thanks fro writing and welcome to the list. We appreciate your will to help as much as we agree any other help. As you probably have noted already we are a bit unsure how to preceed from now. Maybe you can start helping with working on the current PDO. This would allow us to see some input from your side that way introducing yourself and your team better. And it also allows you to understand the way PHP gets developed better. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
On 28.02.2008, at 15:19, Marcus Boerger wrote: Hello David, Wednesday, February 27, 2008, 9:27:16 PM, you wrote: Greetings, PDO community! My name is David Sceppa and I am a program manager working at Microsoft on improving SQL Server for PHP data hosting. Thanks fro writing and welcome to the list. We appreciate your will to help as much as we agree any other help. As you probably have noted already we are a bit unsure how to preceed from now. Maybe you can start helping with working on the current PDO. This would allow us to see some input from your side that way introducing yourself and your team better. And it also allows you to understand the way PHP gets developed better. I would also like to welcome you here. Is this the first time someone has posted to a php.net mailinglist with an @microsoft.com address? Anyways not requiring either the core or the spec to be under a CLA is getting in the direction of where things can work out. Getting to know you and some of the other developers is also another important step. Other topic. Not sure if I have mentioned this, but has anyone contacted Ingres yet. I am CC'ing Grant from Ingres who is maintaining ext/ingres .. maybe he can shed some light .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
On Wednesday 27 February 2008, David Sceppa wrote: The approach that's been described in proposals (vendor-built drivers can be covered via CLAs while the core components remain CLA-free) is something I believe to be in the best interests of both driver writers and the developers who use PDO. We would prefer to have the spec and the core covered by CLA, so that we can make more direct contributions, yet we understand that the community wishes to keep the spec and the core CLA-free. I am curious. If PDO core itself did not have a CLA, what direct contributions would you (Microsoft, not you personally) not be able/willing to make that you would be able/willing to make if it were? And is it able or willing? I think that's the question many people still don't have a clear answer to (from any DB vendor, at least that I've seen). -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Lester Caine wrote: Perhaps if PDO actually added some value there there would not be a problem, but we still need something sensible wrapping it to make cross database SQL work so why do I need to bother changing the internals of what I have been working with for years just to 'fix half of the problem' with a solution at is still showing a significant decrease in performance over native drivers managed transparently in ADOdb. You miss the unstated implication that PDO V2 will offer par or better performance, and potentially more functionality. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Hi, Pierre Joye wrote: Hi, I think the biggest myths in this CLA discussion are: 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. and: 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. --Wez. The history of open sources and free softwares (generally speaking, not specifically FSF) tells us that they can work without restrictions, of any form. If one has doubts, he can look at the X.org projects or any other areas where NDA and CLA are (I can soon say were) a must have. Almost all vendors are now opening theirs specs and collaborate with the respective open source projects. Their teams even provide patches and improvements on a regular basis. How does it happen? The project leaders knew that vendors will have no choice in the end. The problem with php is that we are easily influenced by a couple of big companies. A couple of invitation here, some special events there and suddenly the old evil is becoming our best friends. But they were not the evil, they are also not out best friends. They simply do their jobs, keep their market share using all well known marketing actions (that's not badly meant). I am following the PDO2 threads since they appeared and stood silent as Jay (Pipes) jumped on explaining the MySQL position. In this email I speak my _personal_ opinion. 1) Was there a problem with having different DB modules all these years? I think - no! 2) Was there a problem of having PDO1 with different DB modules? The core is clean, the modules are buggy but imagine how all these things work without even a specification. Actually the specs appeared as part of the PDO2 discussion. Now there is a spec and it should be non-CLA or we should invent one that is non-CLA-ed from the most common behavior of the drivers. The the DB vendors should go and fix what they have, or pay someone to do it, or risk an entry on the wall of shame. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Hi, I think the biggest myths in this CLA discussion are: 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. and: 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. --Wez. The history of open sources and free softwares (generally speaking, not specifically FSF) tells us that they can work without restrictions, of any form. If one has doubts, he can look at the X.org projects or any other areas where NDA and CLA are (I can soon say were) a must have. Almost all vendors are now opening theirs specs and collaborate with the respective open source projects. Their teams even provide patches and improvements on a regular basis. How does it happen? The project leaders knew that vendors will have no choice in the end. The problem with php is that we are easily influenced by a couple of big companies. A couple of invitation here, some special events there and suddenly the old evil is becoming our best friends. But they were not the evil, they are also not out best friends. They simply do their jobs, keep their market share using all well known marketing actions (that's not badly meant). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Be fair, this is an open list. Anyone can join it, and it keeps the noise levels down on [EMAIL PROTECTED] Please? ;) http://news.php.net/php.pdo - Steph - Original Message - From: Marcus Boerger [EMAIL PROTECTED] To: Wez Furlong [EMAIL PROTECTED] Cc: Steph Fox [EMAIL PROTECTED]; [EMAIL PROTECTED]; internals@lists.php.net 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
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Steph Fox wrote: Be fair, this is an open list. Anyone can join it, and it keeps the noise levels down on [EMAIL PROTECTED] Please? ;) http://news.php.net/php.pdo Move all of PDO over to there and let those of us who have not found any reason to need to switch to it get on with fully open source development :) Perhaps if PDO actually added some value there there would not be a problem, but we still need something sensible wrapping it to make cross database SQL work so why do I need to bother changing the internals of what I have been working with for years just to 'fix half of the problem' with a solution at is still showing a significant decrease in performance over native drivers managed transparently in ADOdb. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
