On 15 June 2010 19:41, Ilia Alshanetsky <i...@prohost.org> wrote: > After speaking to a few developers in DPC, I think it makes sense for us to > drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 > extensions. The sqlite2 library is no longer maintainer and the migration > path from version 2 to 3 is very simple. Unless there any objections, I'd > like to make this happen in the next week or two.
Funnily enough, we had a short discussion about this on IRC last week; I was meaning to write an RFC before getting swamped at work. My feeling (and I'm speaking just for myself here) is that we can't really get rid of ext/sqlite in the short to medium term: people have gotten too used to having it available and bundled in a default PHP installation. Obviously, though, we can't really keep bundling an unmaintained library, either, and we should start nudging people gently towards sqlite3. What I'd prefer: – Deprecate ext/sqlite in trunk, at least by having sqlite_open() generate an E_DEPRECATED warning. – Unbundle libsqlite2 in the next major version after what's currently in trunk and disable the extension by default, but still allow compilation against an external libsqlite2 if the user really wants to. – Move ext/sqlite to PECL at some point thereafter. PDO would be handled similarly. If someone has some real world numbers on the use of ext/sqlite, that might be handy. From where I sit, though, it does seem to have become a bit of a standard, so I'd rather not pull the rug out from under people that suddenly — particularly given it's not even deprecated at the moment. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
