Re: MySQLi Compat question

I would really prefer to see a single MySQL extension that spoke both v3 and v4. I think the cleanest and easiest way would be to make ext/mysqli backward compatible with the v3 API and at the same time make it forward compatible with the V4 API. Ultimately for the end user this is the most flexible. If they have code (and just about everyone does) written against the current /ext/mysql functions, it should "just work" without them having to mess with anything. But if they want to write code against the V4 API and they have compiled in the v4 client library, then that should work as well. I don't feel like answering the "Which MySQL extension should I use?" question 500 times a month. So, the above was the practical user-experience focused view of this. Now for the much uglier license view. Given the fact that all new v3 and v4 mysql client libraries are under the GPL with an special exception for OSI-licensed open source projects, it would be extremely useful if our standard MySQL extension could be built against the older non-GPL'ed client libraries. -Rasmus On Mon, 9 Jun 2003, John Coggeshall wrote: > On Mon, 2003-06-09 at 14:32, George Schlossnagle wrote: > > I'm in general for this sort of thing (perhaps a new Compat toplevel > > 'namespace'). But have the license issues been worked out with mysqli > > yet? Last I check it was on the verge of being de-bundled. > > I know nothing of that, actually :) > > > Also (since this mail is clearly stream-of-consciousness), how about > > juts adding the compat functions into the mysqli extension itself and > > adding a --mysqli-enable-compat flag or some such. > > Sure, it could be done at the C level but one of the big "improvements" > of the mysqli extension was that it more closely reflected the true > MySQL API (that's what was explained to me). Since one of the clear > goals of mysqli was to eliminate these "magical" non-api PHP functions, > it seems more reasonable to just have the solution be in user-space > instead of starting down the road of aliases and non-api calls again > (although mysqli does still have a few non-api PHP functions still -- > look in mysqli_nonapi.c). > > Assuming mysqli is going to become the standard for database access in > PHP5/the future, my motivation for this proposal is simply to provide a > bridge for the mysql->mysqli transition. This layer allows someone > basically to pull PHP5 out of the box, compile it using the latest and > greatest extension and provide a clean *temporary* backward > compatibility until they can upgrade their code to use "native" mysqli > calls. They can just stick the include file in their auto_include and > their up and running, without adding a lot of unnecessary magic to the > extension itself. > > John > > > On Monday, June 9, 2003, at 12:07 PM, John Coggeshall wrote: > > > > > > > > Hello all. > > > > > > Sterling directed me toward these parts regarding a MySQL/MySQLi > > > compatibility layer [*] I've been doing some work on. Basically, the > > > purpose is to eliminate the need to have two separate extensions > > > installed (both mysql and mysqli) by implementing in the mysql > > > extension > > > functionality as user-space functions which are based in mysqli. > > > > > > I've had good success on my own systems with this script, and thought > > > that it might be something that might be extremely useful for inclusion > > > when PHP5 rolls out the door. I've got most of the functionality > > > implemented and would implement the remaining handful of functions, > > > etc.If there's interest. > > > > > > (I am not on this list so please CC me) > > > > > > John > > > > > > [*] > > > http://www.coggeshall.org/downloads/mysql2mysqli.tar.gz > > > > > > > > > -- > > > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- > > > John Coggeshall > > > john at coggeshall dot org > > > http://www.coggeshall.org/ > > > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- > > > > > > -- > > > PEAR Development Mailing List (http://pear.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- George Schlossnagle > > -- Principal Consultant > > -- OmniTI Computer Consulting, Inc. > > -- +1.410.872.4910 x202 > > -- 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 > > > -- > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- > John Coggeshall > john at coggeshall dot org > http://www.coggeshall.org/ > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >