Re: [PDO] [RFC] An Idea for PDO 2
[email protected] (Christopher Jones)
| Newsgroups | php.pdo |
|---|---|
| Message-ID | <[email protected]> |
Lukas Kahwe Smith wrote: >> We'd support this. From my last set discussions internally, we'd need >> the spec to be under CLA. > > Ok, thats a problem. I do not see much of a chance to convince anyone on > php.net to do this. What other extensions have been written using an external (to PHP) specification? > But lets say its not under a CLA, how is this different than you > guys using the ZE2 API? Is it just because Oracle considers anything > closer to RDBMS to be more of a risk? If we say that we do not > expect much direct collaboration at all from any of the concerned > vendors, is that still an issue? Using is different to contributing to a specification. And collaborating is different to working individually. (And the more that our legal team understood about PHP, the less they liked that management had already approved me contributing...) I think it's an issue for PHP if not all the data access providers can contribute. >> From my point of view, the interesting crux of the PDO discussions is >> that the development and release _process_ is the key factor in >> determining what risk (and hence need for CLA's and licenses) exists. > > Right. The base line is that anyone can setup a PEAR channel and > distribute PHP or C code on their own infrastructure. We are looking if > there is a way to more closely integrate you guys into the php.net > infrastructure. Installation of PHP continues to be the number one barrier to entry issue I see, despite the maturation of various *AMP distros, Zend Core, and other prebuilt stacks. Reducing the barrier is the key reason to have PDO and its drivers integrated with PHP to a high level. It also makes sense to have a central place for documentation and bug reports. 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