Re: [PDO] [RFC] An Idea for PDO 2

Hi Wez, thanks for getting back to me.

> 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.

No point in IRC-watching, everybody's saying the same things in there. 
That's not discussion either.

> No, I didn't say that there's no problem, I said that this sounds 
> reasonable.

Fair enough.

> 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.

We just had mysqlnd added to the core - please don't tell me we're going to 
end up with an open library but a CLA'd PDO module to run on it?

I dunno Wez. Seems to me that that old 'not-PECL' module should be revived 
for CLA'd stuff, at least then there are no surprises for anybody. They get 
their slot in the php.net repository, we get to retain our unblemished souls 
etc. I agree with the others (and from the sound of it, you) that PDO and 
specs ought to be core and free, whatever happens to the rest. So I guess 
that's a starting point.

>> 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.

Yeah - you're focusing on this one area, I was talking more generally about 
the last couple of years. I don't think a quick resolution for the immediate 
PDO problem is a good way to approach the long-term PECL/PHP problem, is all 
I was trying to say. You're right, it's a whole different can of worms.

> 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.

That wasn't really a 'finer point' - Marcus was talking about moving stuff 
out of core, as in killing symlinks. That actually would impact on the 
current eco-structure, such as it be, and we don't have anything to replace 
it with.

>> 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.

:) I'll bet. But we still don't really know what the problems are from their 
perspective, or how many companies think this way or that way. I suspect 
everybody's more than aware of the issues from our perspective now, if they 
weren't a week ago...

> 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.

Sad. I'm resisting the temptation to say... oh, guess.

- Steph

>
> --Wez.