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

 Hi Andi,

For some reason there are no >'s here... so bear with the mess.

=============
Here is a short recap of what I remember (NOTE:
Just because they were raised doesn't mean that people necessarily
thought they were good ideas. It was more on the brainstorming side):
- JDBC like solution - Spec only as a set of interfaces/contracts (also
under some collaboration agreement although there may be an option not
to have that); drivers are fully implemented by the vendors; there is no
PDO core in this option. I didn't like this for three reasons; we lose
the advantage of having shared infrastructure for the various drivers
which ultimately may make it harder to make fixes and/or improvements
propagate to the various drivers, it may encourage less sharing of
knowledge between the vendors, and we would need to deal with symbol
namespacing issues to make sure the different drivers don't clash at
runtime.
- Developing PDO outside of PHP.net - I didn't like this because I
believe PDO is a strategic technology for PHP allowing us to finally
have good consistent DB support in PHP (we have always had large
fluctuations in APIs and quality for the native drivers). I don't see a
non-PHP.net project that isn't part of the community really succeed in
delivering what I think we'd need.
- Developing outside of PHP.net and then copying snapshots into PECL
(variation of previous one) and I don't like this either :)
=============

Thank you for sharing :) I agree the JDBC way sounds a bad option all round.

Pragmatically speaking, I'm not actually certain what the difference is 
between 'developing outside of php.net and then copying snapshots into PECL' 
and 'developing under a CLA in PECL and then releasing into the core'. Both 
approaches have the potential to lead to a split in the codebase if anyone 
does anything with the copied/released version. I'm also wondering vaguely 
about the possibility of hosting CLA'd stuff in a separate area of the 
php.net repository... but that's largely on ideological grounds rather than 
on practical grounds. It would address the fear expressed earlier by several 
people (including Marcus) of 'PHP being owned by companies piece by piece', 
but how it would fit into the infrastructure's a whole different thing.

=============
Also,
by separating what is PHP core, and what actually ends up in our
"release" tar ball we draw a clearer line for committers while making
sure that our end-users receive the best out-of-the-box experience
possible.
=============

In theory, yes. In practice we all know there's a huge amount of user 
confusion about PECL extensions vs core extensions; we keep trying to 
separate these two issues, but we can't pretend the PECL/PHP problem is just 
going to go away overnight because it's finally become inconvenient today. I 
have to say I'm pretty alarmed about the apparent willingness on all sides 
to make things even more confusing :\  This needs serious thought. For 
example, should anything non-essential really be shipped with the core at 
all? And if not, how will end users know which PECL extensions they're 
likely to need, or which are stable? And if you're only talking about 
development here (I can't see it staying this way but...) then we'll need to 
start enforcing rules on PECL that aren't enforced right now. Examples: PECL 
extensions that are enabled by default according to their config files; PECL 
extensions that are particularly exception-happy; PECL extensions that lack 
user documentation; CVS branch usage; a sane way of marking whether an 
extension is in alpha, beta or a stable stage of development. I'm not 
fighting a change - in fact I've been asking for a change for some years now 
in this area - I'm just asking everyone to think through the consequences 
before leaping into the dark.

==============
Re: the licensing suggestions Marcus makes, I'd prefer to try not change
the PHP license if possible but rather have a PDO license which works
for the CLA. Theoretically (need to check this one) the PHP Group could
sub-license the PDO drivers to PHP under the PHP license if that makes a
significant difference; but like a lot of the other BSD-style licensed
code which we include with PHP, I think bundling PDO licensed code
wouldn't be a significant change to existing policy.
==============

Depending on what this theoretical PDO license looks like, I agree that that 
could work.

==============
To summarize, I think given the feedback and discussions which have
occurred in the community I believe it makes sense to explore whether
the vendors would be able to contribute their guidance to the spec
without CLA. The community would then proceed to develop the PHP Core
without a CLA, but then enable the vendors who want to develop and
maintain their vendor-specific PDO drivers under CLA.
==============

I don't think anyone at the php.net end will argue with the first part of 
that at least :)

- Steph