Re: [PDO] PDO2 as a set of PECL extensions, rather than PHP core?

I can't easily reply to newsgroups. So I'll say it here instead.

I thought Ben's suggestion was good.

- Steph

----- Original Message ----- 
From: "Jay Pipes" <[email protected]>
To: "Ben Ramsey" <[email protected]>
Cc: <[email protected]>; "Dan Scott" <[email protected]>; "Steph Fox" 
<[email protected]>
Sent: Monday, January 28, 2008 7:56 PM
Subject: Re: [PDO] PDO2 as a set of PECL extensions, rather than PHP core?


> Actually, Ben, this is an option that we discussed quite at length, and 
> one that I have been hoping someone in the community would bring up again. 
> 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.
>
> As I have stated in the past, it is my personal opinion that it is best to 
> let the community discuss and resolve the issues of the CLA in an open 
> matter and to support the end compromise/solution in whatever ways I (and 
> MySQL) can.  There are cases for and against CLAs and now with various 
> blog posts from Marco Tabini, Lukas, Bill Karwin, Derick, and others, the 
> issues are now being more clearly and effectively outlined (versus the "NO 
> WAY" reactions).  I have good hopes that the community can come to a 
> timely resolution to the issues that will work for all parties involved. 
> Perhaps your solution (non-CLA core&spec, CLA-optioned drivers) is the 
> solution which may best work, but only time and open discussions will 
> tell.
>
> Cheers,
>
> jay
>
> Ben Ramsey wrote:
>> On 1/28/08 12:54 PM, Dan Scott wrote:
>>> On 28/01/2008, Steph Fox <[email protected]> wrote:
>>>> Hi Dan,
>>>>
>>>>> Those non-CLA signing people could even change the code in core, too,
>>>>> if they felt that it was warranted. They would be contributing to a
>>>>> derivative work, not to PDO2 itself.
>>>> That's where the plan falls down. It would be **symlinked**.
>>>
>>> But it doesn't have to be symlinked. That's just the way that things
>>> are done currently, right? Code could just be continually copied and
>>> merged from the PECL repository into core to maintain the core PDO's
>>> derived state.
>>>
>>> Alternately, PDO could be pulled out of core. When you download and
>>> install Perl, you don't get DBI - you have to get that separately
>>> (well, maybe not on Windows, depending on the distributor's
>>> package...). I'm pretty sure the same is true for Python (as there is
>>> no core DBI package in Python, just db drivers that implement the DBI
>>> interface). Does it really matter if PDO is part of the php-src CVS
>>> directory or not?
>>>
>>
>> What if PDO2 was essentially an API for writing a DB driver (a la 
>> pecl/pdo_user, though not providing the API at the userland level)? I 
>> know it somewhat serves that function now, but PDO2 would be a better API 
>> with better documentation. The PDO2 code would be in the core and not 
>> under any kind of CLA. Then, the various database vendors could develop 
>> drivers for PDO2 based on that API, and the code could live on their 
>> sites or in PECL, depending on how they choose to license their code. It 
>> would benefit them more, however, and allow them to better compete 
>> against other database companies if they choose to open source their PDO2 
>> drivers and provide them to the community from PECL, so I think there is 
>> a big incentive for them to do so.
>>
>> Then again, maybe I'm over-simplifying things. :-)
>>
>> -- 
>> Ben Ramsey
>> http://benramsey.com/
>>