Re: Re: PHP 5.0.0 Beta 1

From: Date: Mon, 30 Jun 2003 02:11:58 +0000
Subject: Re: Re: PHP 5.0.0 Beta 1
References: 1 2 3 4 5 6 7 8 9  Groups: php.pear.general 
Request: Send a blank email to pear-general+get-6320@lists.php.net to get a copy of this message
http://www.hwaci.com/sw/sqlite/ Has some docs. The PHP-specific docs are coming. And to answer your questions, if your server has sqlite support and you have permission to create files in your web directory, then you have sqlite access. Your ISP doesn't need to do anything as it is just a fancy way to manipulate text files directly. I still don't see this significantly changing the availability of MySQL on hosts. Most ISP's likely always compile PHP against their system libmysqlclient anyway, so I would be very surprised if you would notice a big drop. -Rasmus On Mon, 29 Dec 2003, Stan Lemon wrote: > Alright, now I'll be honest... I don't know anything about SQLite. I > downloaded the executable today, so that I could look at it for the > future of PHP. I am unclear as to how to use it, and where to go with > it. Also, is SQLite supported by DB or MDB? I guess the big question > is, is there a guide somewhere for newbies to SQLite so that a > know-nothing like myself might be able to get familiar with it? Also, > seeing as SQLite is not a server, is it possible for me just to upload a > binary to my *nix host, and use that, rather then go through the torment > of asking them to put one up for me. (I'm still waiting for them to > properly install PEAR....) Also, what's the speed diff. between SQLite > and mySQL? > > - Stan > > Rasmus Lerdorf wrote: > > >Right. We tried to address this point by providing a bundled sqlite > >library. This is a cool extension which provides you with an SQL > >interface onto flat files. No server required. > > > >There is no malicious intent here. MySQL changed their license on the new > >client libraries and we had to decide if we wanted to continue to bundle > >the older library, which admittedly we could do without any license > >problems, but as people upgrade their servers, this older library will > >become less and less useful. We figured the cleanest solution was to make > >a clean break in PHP 5 and let people install their own client library to > >match their installed server. > > > >-Rasmus > > > >On Sun, 29 Jun 2003, Stan Lemon wrote: > > > > > > > >>I still feel eerie, it'll be more of a hastle for me, and I'm not big on > >>that. Part of the problem I am going to be facing is developing in PHP > >>on Windows. Since I am essentially = to poor, the SQL servers (for > >>Windows) which cost money (ehem, mostly everything but mySQL), will be > >>unavailable to me. The bigger problem will be when I drop stuff onto my > >>web host where I, more then likely, won't find the same SQL db. I may > >>have to resort to the old fashion way of doing things, like my buddy > >>still does in Perl... arg... parsing text files. :-( > >> > >>- Stan > >> > >>Rasmus Lerdorf wrote: > >> > >> > >> > >>>What's the confusion here? Most non-GPL licenses are not compatible with > >>>the GPL when it comes to combining a GPL'ed and the non-GPL'ed component > >>>in the same package. This has nothing speficially to do with PHP. You > >>>also cannot link a GPL'ed libmysqlclient library into Apache in any way > >>>and redistribute that. So, something like mod_auth_mysql has that > >>>problem. > >>> > >>>This presents less of a problem to the end users. If you are not planning > >>>on redistribution you can pretty much do whatever you want. As software > >>>providers we are more inconvenienced by this. We cannot, for example, > >>>distribute code whose only purpose is to link against a GPL'ed library. > >>>I personally think potential linking restriction is beyond what the GPL > >>>can cover since we aren't including any GPL'ed code, but RMS disagrees > >>>and > >>>loves to beat on us for it. RMS's view is that if we distribute software > >>>which is only useful if it is linked against a GPL'ed library then we are > >>>indirectly violating the GPL by encouraging people to violate the license. > >>>Our ext/readline extension was a sore point for a while until we made it > >>>clear that the extension was aimed at the BSD-licensed libedit library > >>>which happens to share the same API as the GPL'ed libreadline. > >>> > >>>In the MySQL case we need to make sure that our MySQL extension can be > >>>linked against a non-GPL'ed library so as to not encourage people to > >>>violate the GPL. And MySQL AB will have some specific terms for > >>>open-source projects like PHP that will make this easier for us. > >>> > >>>You really shouldn't worry very much about this. Neither the PHP > >>>developers nor the MySQL developers want to make life difficult on > >>>PHP-MySQL users. We may not bundle libmysqlclient anymore, but that > >>>doesn't mean that we will drop MySQL support. The bundled library did > >>>cause some problems over the years with mismatched libraries and in the > >>>end you are better off having a single libmysqlclient library on your > >>>system that you link everything against instead of having some stuff > >>>linked against one version of the library and other stuff linked against > >>>another. > >>> > >>>-Rasmus > >>> > >>> > >>>On Sun, 29 Jun 2003, Stan Lemon wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Could be. All I'm saying is I have a feeling that's the part of the > >>>>license they are having a conflict with. > >>>> > >>>>Regardless... This brings a *serious* issue up for PHP, especially > >>>>since mySQL is so common amongst open source developers. Unless there > >>>>is some change it makes me hesitant to PHP5. > >>>> > >>>>- Stan > >>>> > >>>>Eric "e-dawg" Johnston wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>But PHP is Open Source. > >>>>> > >>>>>Might it be due to Zend? > >>>>> > >>>>>On Sun, 2003-06-29 at 18:56, Stan Lemon wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I am assuming the following: > >>>>>> > >>>>>> > >>>>>> 3. Commercial use for everyone else > >>>>>> > >>>>>>b) If you include one of the MySQL drivers in your non Open Source > >>>>>>application (so that your application can run with MySQL), you need a > >>>>>>commercial licence for the driver(s) in question. The MySQL drivers > >>>>>>currently include an ODBC driver, a JDBC driver and the C language > >>>>>>library. > >>>>>> > >>>>>>Robert Cummings wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I read the licensing information in the above link, but I'm > >>>>>>>curious what > >>>>>>>exactly in it necessitated the need to unbundle MySQL? Anyone have > >>>>>>>a > >>>>>>>quick answer? > >>>>>>> > >>>>>>>Cheers, > >>>>>>>Rob. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>PEAR General Mailing List (http://pear.php.net/) > >>>>To unsubscribe, visit: > >>>>http://www.php.net/unsub.php > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >>-- > >>PEAR General Mailing List (http://pear.php.net/) > >>To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> > > > > > > > > > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.pear.general (#6320) next »