> -----Original Message----- > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 14, 2008 2:15 PM > To: Christopher Jones > Cc: Pierre Joye; [EMAIL PROTECTED]; PHP Internals > Subject: Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: > [PHP-DEV] [RFC] An Idea for PDO 2 > -snip- > > As such the only course of action I currently is to start working. If > you guys do not feel like you can work within the current legal bounds > of php.net, then I suggest you start working outside of them. Once we > see actual value being contributed, the willingness to compromise and > change will be much higher.
It's a bit of a chicken&egg problem. The idea was to find a way for this to happen which would work long term for the project. This includes both the contribution process and then the distribution process. Theoretically working on this separately is an option the same way you have Propel for DB abstraction, Midnight Coders for Flex, NuSOAP for SOAP, etc... However we see this as an important core component for PHP and a lot of these processes can't just be changed/reversed once they are set in motion. For example, if this is developed separately then I assume there'd be no problem in having a legal entity (you mentioned some of the other standards bodies who are also entities). The issue will pop up when there are successes and we all believe it's beneficial to roll it into PHP. So instead we tried to come up with a proposal which would enable the long term feasibility and create a feasible path ahead of time. As an example with the legal entity issue we managed to get buy in for using PHP Group (not trivial, or should I even say, unprecedented). Anyway it's still an option but not the preferred one. I'd be interested to hear more about the ideas people had on how we can possibly decouple some of the packaging decisions and where the actual work happens. There'd obviously still need to be certain requirements including compatible licenses, integration into bug tracker (possibly), and configuration management guidelines, but maybe others have ideas for ways to accomplish the goals in a way which could still work for most people and allow the vendors to have some of their best people to fully participate. I say most because 100% of people are never happy including in all the million other discussions we have had on other topics over the years. Anyway, let's continue this discussion but with the intent to make a best shot at some ideas for how to achieve some of the goals I think the majority of us would like to see a PDO which includes a first-class PDO with the necessary functionality and consistency, high-quality and consistent drivers across all data access APIs, and well documented functionality. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
