Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » enabling sqlite by default »

enabling sqlite by default

php.internals

Sterling Hughes

23 years ago
Hey, Unless anyone objects I'm going to enable the sqlite extension by default for PHP5. The extension comes with the bundled sqlite library which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), and is a good alternative to using MySQL for small sites. The sqlite library is licensed to the public domain and provides a complete database solution in a small library - no server required. For more information take a look at http://www.hwaci.com/sw/sqlite/. -Sterling
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

George Schlossnagle

23 years ago
On Sunday, June 22, 2003, at 10:38 PM, Sterling Hughes wrote:
> Hey, > > Unless anyone objects I'm going to enable the sqlite extension by > default for PHP5. The extension comes with the bundled sqlite library > which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > and is a good alternative to using MySQL for small sites.
We should add --without-kitchen-sink to disable all these new bundled extensions. George

Sterling Hughes

23 years ago
--disable-all you mean? -Sterling On Sun, 2003-06-22 at 23:47, George Schlossnagle wrote:
> On Sunday, June 22, 2003, at 10:38 PM, Sterling Hughes wrote: > > > Hey, > > > > Unless anyone objects I'm going to enable the sqlite extension by > > default for PHP5. The extension comes with the bundled sqlite library > > which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > > and is a good alternative to using MySQL for small sites. > > We should add > > --without-kitchen-sink > > to disable all these new bundled extensions. > > George
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

George Schlossnagle

23 years ago
On Sunday, June 22, 2003, at 11:39 PM, Sterling Hughes wrote:
> --disable-all you mean?
Well, certain extension (curl, openssl) are almost necessary for the language itself to be fully functional, whereas sqlite is just a db extension. It being present at compile time doesn't alter the way the language itself behaves. But yes, I was being a bit snarky about the things that get bundled in and enabled by default. George
> > -Sterling > > On Sun, 2003-06-22 at 23:47, George Schlossnagle wrote: >> On Sunday, June 22, 2003, at 10:38 PM, Sterling Hughes wrote: >> >>> Hey, >>> >>> Unless anyone objects I'm going to enable the sqlite extension by >>> default for PHP5. The extension comes with the bundled sqlite >>> library >>> which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c >>> *.h), >>> and is a good alternative to using MySQL for small sites. >> >> We should add >> >> --without-kitchen-sink >> >> to disable all these new bundled extensions. >> >> George > -- > "A business that makes nothing but money is a poor kind of business." > - Henry Ford > > -- > PHP Internals - PHP Runtime Development Mailing List > 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

Sterling Hughes

23 years ago
On Sun, 2003-06-22 at 23:52, George Schlossnagle wrote:
> On Sunday, June 22, 2003, at 11:39 PM, Sterling Hughes wrote: > > > --disable-all you mean? > > Well, certain extension (curl, openssl) are almost necessary for the > language itself to be fully functional, whereas sqlite is just a db > extension. It being present at compile time doesn't alter the way the > language itself behaves. >
Well, its not 'just a db extension.' Its a DB as well :) The idea of bundling SQLite is that alot of things with PHP are about saving and remembering data. Whether its a hit counter, a poll script, a weblog, etc. In these cases using a RDBM is overkill, but using a flat file or DBM file is a pain in the ass. This is especially true on shared hosts that may not always provide a database server, or may provide wierd table permissions. SQLite provides a very simple interface to managing files using the SQL language. It takes care of the locking, the data format, the low-level access routines, etc. All you need to worry about is a little bit o' SQL. Having this always available is a great boon to our users. -Sterling
-- "The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea." - Unknown

Derick Rethans

23 years ago
On Sun, 22 Jun 2003, George Schlossnagle wrote:
> We should add > > --without-kitchen-sink > > to disable all these new bundled extensions.
--disable-all is what you have for that Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Andi Gutmans

23 years ago
At 10:38 PM 6/22/2003 -0400, Sterling Hughes wrote:
>Hey, > >Unless anyone objects I'm going to enable the sqlite extension by >default for PHP5. The extension comes with the bundled sqlite library >which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), >and is a good alternative to using MySQL for small sites. > >The sqlite library is licensed to the public domain and provides a >complete database solution in a small library - no server required. For >more information take a look at http://www.hwaci.com/sw/sqlite/.
On one hand I think having 1.5MB in our release tree is quite a lot (can anything be removed)? On the other hand, I think bundling and enabling this by default will really help lots of small users who have a web account but no DB access. So I'm around a +0 :) Andi

Sterling Hughes

23 years ago
On Mon, 2003-06-23 at 02:03, Andi Gutmans wrote:
> At 10:38 PM 6/22/2003 -0400, Sterling Hughes wrote: > >Hey, > > > >Unless anyone objects I'm going to enable the sqlite extension by > >default for PHP5. The extension comes with the bundled sqlite library > >which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > >and is a good alternative to using MySQL for small sites. > > > >The sqlite library is licensed to the public domain and provides a > >complete database solution in a small library - no server required. For > >more information take a look at http://www.hwaci.com/sw/sqlite/. > > On one hand I think having 1.5MB in our release tree is quite a lot (can > anything be removed)? On the other hand, I think bundling and enabling this > by default will really help lots of small users who have a web account but > no DB access. >
Well, its actually already bundled. If you've cvs updated then you have SQLite already bundled. SQLite is in PECL, and the PECL version bundles the library. 1.5 mb is tiny :) -Sterling
> So I'm around a +0 :) > > Andi
-- Good judgement comes from experience, and experience comes from bad judgement. - Fred Brooks

Andi Gutmans

23 years ago
At 01:01 AM 6/23/2003 -0400, Sterling Hughes wrote:
>Well, its actually already bundled. If you've cvs updated then you have >SQLite already bundled. SQLite is in PECL, and the PECL version bundles >the library. 1.5 mb is tiny :)
I think it's probably time to update makedist so that it also brings stuff from PECL (the stuff we decide on obviously). Can't the 1.5MB be cut down a bit? Changelog files, jpgs :) Andi

Sterling Hughes

23 years ago
1.5 mb is tiny :) 1.5 mb is just a du -ch *.c *.h, and its a one time download. Then you cvs upd the rest of the changes as they happen. As a point of reference, the mbstring extension is 2.9 mb of data, sqlite is in total 1.9 mb of data. Libmysql was much more code than the bundled sqlite is. But besides that, I'm talking about enabling by default - not bundling. As I mentioned its been bundled for quite awhile now. :) -Sterling On Mon, 2003-06-23 at 02:16, Andi Gutmans wrote:
> At 01:01 AM 6/23/2003 -0400, Sterling Hughes wrote: > > >Well, its actually already bundled. If you've cvs updated then you have > >SQLite already bundled. SQLite is in PECL, and the PECL version bundles > >the library. 1.5 mb is tiny :) > > I think it's probably time to update makedist so that it also brings stuff > from PECL (the stuff we decide on obviously). > Can't the 1.5MB be cut down a bit? Changelog files, jpgs :) > > Andi
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

Sebastian Bergmann

23 years ago
Sterling Hughes wrote:
> As I mentioned its been bundled for quite awhile now. :)
But only hours ago it was symlinked from PECL to php5 :)
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ http://www.professionelle-softwareentwicklung-mit-php5.de/

Andi Gutmans

23 years ago
At 01:12 AM 6/23/2003 -0400, Sterling Hughes wrote:
>1.5 mb is tiny :) > >1.5 mb is just a du -ch *.c *.h, and its a one time download. Then you >cvs upd the rest of the changes as they happen. As a point of >reference, the mbstring extension is 2.9 mb of data, sqlite is in total >1.9 mb of data. > >Libmysql was much more code than the bundled sqlite is. But besides >that, I'm talking about enabling by default - not bundling. As I >mentioned its been bundled for quite awhile now. :)
It's been bundled in the 4.3.x releases? :) I guess I completely missed that part. Anyway, once it's bundled I am definitely +1 for enabling it by default. I didn't know it was bundled (and I'm not talking about CVS but in a release). Andi

Sterling Hughes

23 years ago
nope, just in cvs. and just as of last night. :) But the footprint of php5 is actually smaller with regards to sqlite, as the client library caused more download time. -Sterling On Mon, 2003-06-23 at 13:58, Andi Gutmans wrote:
> At 01:12 AM 6/23/2003 -0400, Sterling Hughes wrote: > >1.5 mb is tiny :) > > > >1.5 mb is just a du -ch *.c *.h, and its a one time download. Then you > >cvs upd the rest of the changes as they happen. As a point of > >reference, the mbstring extension is 2.9 mb of data, sqlite is in total > >1.9 mb of data. > > > >Libmysql was much more code than the bundled sqlite is. But besides > >that, I'm talking about enabling by default - not bundling. As I > >mentioned its been bundled for quite awhile now. :) > > It's been bundled in the 4.3.x releases? :) I guess I completely missed > that part. > > Anyway, once it's bundled I am definitely +1 for enabling it by default. I > didn't know it was bundled (and I'm not talking about CVS but in a release). > > Andi
-- "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup

Wez Furlong

23 years ago
When I bundled the library, I only included the required files (the official distro is a bit larger than what we include in ext/sqlite). --Wez. On Mon, 23 Jun 2003, Andi Gutmans wrote:

Thies C. Arntzen

23 years ago
On Sun, Jun 22, 2003 at 10:38:42PM -0400, Sterling Hughes wrote:
> Hey, > > Unless anyone objects I'm going to enable the sqlite extension by
i object strongly. sterling, why have you gotten into the enable-all, bundle-all mode lately? what do you gain? thies

Sterling Hughes

23 years ago
On Mon, 2003-06-23 at 03:55, Thies C. Arntzen wrote:
> On Sun, Jun 22, 2003 at 10:38:42PM -0400, Sterling Hughes wrote: > > Hey, > > > > Unless anyone objects I'm going to enable the sqlite extension by > > i object strongly. sterling, why have you gotten into the > enable-all, bundle-all mode lately? what do you gain? >
Well, I wouldn't say I'm in the enable-all, bundle-all mode. But I'll talk a little bit about why SQLite is über-cool, and why I think should always be enabled. Many times in PHP you don't really need a RDBM. Whether its building a weblog system, writing a Polling system, or a small content management system. In these cases many people either misuse a RDBM, causing major headaches, or they use flatfiles, which cause even larger headaches. Whoops, I forgot to lock. Whoops, I used fread() on 20k of data, when I only need 2k. Whoops, I seek'ed through an entire directory, searching for a file. Whoops, this is getting annoying, isn't it? ;-) In these cases, where you don't have the necessity of a transaction based environment, and you aren't write-heavy, SQLite is a godsend. It provides a very intelligent file management and indexing system, coupled with a data abstraction interface - SQL. I imagine SQLite to be used inplace of custom flatfile systems, and custom flatfile management. Its a small, low-level library that manages optimizes and manages file access and manipulation. Did I mention it also cooks your toast? The second reason I want this enabled by default is that SQLite is the end-to-end solution. No database server required. This means when installed on shared hosting providers, they don't have to worry about permissions management, performance issues, access partitioning, replication, etc. You as the PHP user also don't need to worry about not having an SQL-esque solution available (it supports a larger subset of ANSI 92 then MySQL btw). SQLite is very respectful of permissions, etc. And, we can make it respect PHP safe mode, open base dir, etc. This makes it very shared host friendly. So why bundle and enable by default? Well three reasons. a) It provides a very low memory footprint. Its initialization costs you nothing, and it only hurts you if you use it. Compare this to libmysql which caused 13% of total execution time in CGI mode, just to find the MySQL port (I fixed this, but still). b) Its a very small code size. Compare sqlite and mbstring for example. 1.9 mb, for the PHP extension, and the source code is absolutely nothing. c) In order for it to be useful for shared hosts, it needs to be always enabled. SQLite isn't yet very popular, and not many people know about it. Having something like this always available can be a great boon to portable application development with PHP. -Sterling
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

Derick Rethans

23 years ago
On Mon, 22 Jun 2003, Sterling Hughes wrote:
> Unless anyone objects I'm going to enable the sqlite extension by > default for PHP5. The extension comes with the bundled sqlite library > which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > and is a good alternative to using MySQL for small sites.
I've no problem if we distribute it by default, but I'm not sure if we need to enable it by default. Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Per Lundberg

23 years ago
On Mon, 2003-06-23 at 04:38, Sterling Hughes wrote:
> Unless anyone objects I'm going to enable the sqlite extension by > default for PHP5. The extension comes with the bundled sqlite library > which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > and is a good alternative to using MySQL for small sites.
+1
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

Zeev Suraski

23 years ago
I think it's a good idea. Zeev At 05:38 23/06/2003, Sterling Hughes wrote:

Dan Kalowsky

23 years ago
-1 As always I'm against any enable by default thinking. Why, oh why, are we making this wonderful configure script completely useless? On Sun, 22 Jun 2003, Sterling Hughes wrote:
> Hey, > > Unless anyone objects I'm going to enable the sqlite extension by > default for PHP5. The extension comes with the bundled sqlite library > which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), > and is a good alternative to using MySQL for small sites. > > The sqlite library is licensed to the public domain and provides a > complete database solution in a small library - no server required. For > more information take a look at http://www.hwaci.com/sw/sqlite/. > > -Sterling >
>---------------------------------------------------------------<
Dan Kalowsky "I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin." dank-nom@aps-deadmime.org - "Streets of Philadelphia", kalowsky@php.net Bruce Springsteen

Philip Olson

23 years ago
-1 People that want to use sqlite can download the source, they can even use the pear command to do this either by: a) pear install sqlite (to create the .so) extension=sqlite.so b) pear bundle sqlite (to download the source) ./configure --with-sqlite Forcing the entire world to have all this source that many will not even use doesn't seem right. Also, just think about those people who actually pay for bandwidth per minute off their modems. But, that's not the point. Nobody should feel obligated to bundle a database, no matter how cool it might be. I'd also like to see an option to do this: pear bundle gd, to download the gd fork, but I digress. This is a wonderful time to promote PEAR and the PECL situation rather than force featured bundles on people, like sqlite. Please reconsider this move and allow people the choice of providing extensions themselves. If it's decided to include it, please offer a download option that doesn't include this/these featured extensions. Regards, Philip

George Schlossnagle

23 years ago
On Tuesday, June 24, 2003, at 09:56 AM, Philip Olson wrote:
> This is a wonderful time to promote > PEAR and the PECL situation rather than force featured > bundles on people, like sqlite.
This is a good synopsis of some of my feelings. PECL == Siberia is a recurrent gripe, but anytime someone works on a cool project they want it to bundle, ship and be enabled by default instead of promoting it out of PECL. George

Pierre-Alain Joye

23 years ago
On Tue, 24 Jun 2003 10:03:51 -0400 George Schlossnagle <george@omniti.com> wrote:
> This is a good synopsis of some of my feelings. PECL == Siberia is a > recurrent gripe, but anytime someone works on a cool project they want > > it to bundle, ship and be enabled by default instead of promoting it > out of PECL.
This is a undesirable sideeffect. Then I really missed the decision process to bundle or not something (kinda I want it, I do it ;-) ). But I'm not concerned by this problem. But about PECL, we definitely need to close the nice discussion started last week by Tomas. Then we can go ahead to setup everything required. pierre

Wez Furlong

23 years ago
Sterling has a good point that sqlite is something that could really boost PHP. Currently, the only way to ensure that it is a standard feature is to enable it by default. Sad but true. My main misgiving with it being enabled by default is that it will make it harder for me to publish releases of the extension between releases of PHP. For the reasons that Sterling has suggested, I'd like to see the sqlite recommended as a default (but don't mind if it isn't). I'd also like it to be upgradable via the pear mechanism. Currently this would mean building it as a shared extension by default. This last point is something that should be considered for the other core extensions (except ext/standard) that will eventually be pickled. (I know Derick has some negative views on building things shared by default; I'll let him speak of those when he finds the time). --Wez.
> This is a good synopsis of some of my feelings. PECL == Siberia is a > recurrent gripe, but anytime someone works on a cool project they want > it to bundle, ship and be enabled by default instead of promoting it > out of PECL.
I'd like to point out that I didn't start this thread...

Sascha Schumann

23 years ago
SQLite should become as pervasive as the session extension. It is really a killer feature. - Sascha

George Schlossnagle

23 years ago
On Tuesday, June 24, 2003, at 10:24 AM, Wez Furlong wrote:
> Sterling has a good point that sqlite is something that could really > boost > PHP. Currently, the only way to ensure that it is a standard feature > is to > enable it by default. Sad but true.
That is true. It's something of a chicken and egg problem. I think the reason that people don't use non-stock configurations is that largely the kitchen sink is enabled in PHP. The less this is true, the more folks will have to consider how they want to build it. Perhaps a '--enable-shared=all' (like apache) or '--enable-hosting' or some such that builds the kitchen sink in.
> > My main misgiving with it being enabled by default is that it will > make it > harder for me to publish releases of the extension between releases of > PHP.
Right. Being able to do this easily is a Good Thing (imho).
> > For the reasons that Sterling has suggested, I'd like to see the sqlite > recommended as a default (but don't mind if it isn't).
I dig including it in ext, and bundling the full sqlite sources as well. I just don't think it should be enabled by default. George

Ilia A.

23 years ago
On June 24, 2003 10:40 am, George Schlossnagle wrote:
> I dig including it in ext, and bundling the full sqlite sources as > well. I just don't think it should be enabled by default.
Enabling sqlite by default has virtually no performance impact. Your binary is increased by roughly 100k and you initialize a dosen or so constants on startup. Comparatively speaking it is much 'nicer' then tokenizer (enabled by default) which initialized couple hundred constants at start up. Ilia

George Schlossnagle

23 years ago
On Tuesday, June 24, 2003, at 10:56 AM, Ilia A. wrote:
> On June 24, 2003 10:40 am, George Schlossnagle wrote: >> I dig including it in ext, and bundling the full sqlite sources as >> well. I just don't think it should be enabled by default. > > Enabling sqlite by default has virtually no performance impact. Your > binary is > increased by roughly 100k and you initialize a dosen or so constants on > startup. Comparatively speaking it is much 'nicer' then tokenizer > (enabled by > default) which initialized couple hundred constants at start up.
I'm not approaching this from a performance standpoint, but from one where statically compiled extensions slow the overall release process, make it difficult for users to incrementally upgrade their extensions, and generally contribute to bloat. George

Ilia A.

23 years ago
On June 24, 2003 10:50 am, George Schlossnagle wrote:
> I'm not approaching this from a performance standpoint, but from one > where statically compiled extensions slow the overall release process, > make it difficult for users to incrementally upgrade their extensions, > and generally contribute to bloat.
I don't see how that would slow the release process. Unless we suddenly adopt a stance where we do not release a new version until ALL bugs in the previous release are fixed the time to make a release would be the same. That said, thanks to PECL we can also simply use the last stable version if the current version of the extension is buggy, unstable, etc... I would imagine that while a number of users compile their own php an even greater number uses the packaging system of their favorite OS. Meaning that their idea of upgrade is something along the lines of "apt_get php". The changes we make would only affect the maintainer, who I am sure can figure what to do. Ilia

Marco Tabini

23 years ago
Why not disable all extensions by default and add a configuration utility that is launched before compilation--sort-of like the Linux kernel? Marco On Tue, 2003-06-24 at 10:56, Ilia A. wrote:
> On June 24, 2003 10:40 am, George Schlossnagle wrote: > > I dig including it in ext, and bundling the full sqlite sources as > > well. I just don't think it should be enabled by default. > > Enabling sqlite by default has virtually no performance impact. Your binary is > increased by roughly 100k and you initialize a dosen or so constants on > startup. Comparatively speaking it is much 'nicer' then tokenizer (enabled by > default) which initialized couple hundred constants at start up. > > Ilia
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Dan Kalowsky

23 years ago
I've proposed such solutions in the past, and only recently have come to dislike the means (but not the idea). Mainly because the mechanism to do such a configuration could lead to a longer configuration time then compile time. On Tue, 24 Jun 2003, Marco Tabini wrote:
> Why not disable all extensions by default and add a configuration > utility that is launched before compilation--sort-of like the Linux > kernel?
>---------------------------------------------------------------<
Dan Kalowsky "I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin." dank-nom@aps-deadmime.org - "Streets of Philadelphia", kalowsky@php.net Bruce Springsteen

Marco Tabini

23 years ago
Even with a menu-driven approach (e.g.: make menuconfig in the kernel)? My thought is that you'd still feed the end result through ./configure, but the app would make it somewhat easier for those who don't have a clue. It would also be possible to distribute "pre-packaged" configurations for common scenarios, thus removing the problem of what to distribute by default. Cheers, Marco On Tue, 2003-06-24 at 10:51, Dan Kalowsky wrote:
> I've proposed such solutions in the past, and only recently have come to > dislike the means (but not the idea). Mainly because the mechanism to do > such a configuration could lead to a longer configuration time then > compile time. > > > > On Tue, 24 Jun 2003, Marco Tabini wrote: > > > Why not disable all extensions by default and add a configuration > > utility that is launched before compilation--sort-of like the Linux > > kernel? > > >---------------------------------------------------------------< > Dan Kalowsky "I'll walk a thousand miles just > http://www.deadmime.org/~dank to slip this skin." > dank-nom@aps-deadmime.org - "Streets of Philadelphia", > kalowsky@php.net Bruce Springsteen
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Gareth Ardron

23 years ago
On Tuesday 24 June 2003 3:51 pm, Dan Kalowsky wrote:
> I've proposed such solutions in the past, and only recently have come to > dislike the means (but not the idea). Mainly because the mechanism to do > such a configuration could lead to a longer configuration time then > compile time.
For those of you who have seen the debconf stuff, how about something like that? Walk through menu of "do you want X enabled? do you want Y enabled?" which just stores as a string and excecutes `./configure {string value}` That way, it's just a bolt-on easy method of writing the configure command for the end user, and advanced users can do the standard style ./configure --with-blah style.
-- Gareth Ardron

Zeev Suraski

23 years ago
At 17:50 24/06/2003, George Schlossnagle wrote:
>On Tuesday, June 24, 2003, at 10:56 AM, Ilia A. wrote: > >>On June 24, 2003 10:40 am, George Schlossnagle wrote: >>>I dig including it in ext, and bundling the full sqlite sources as >>>well. I just don't think it should be enabled by default. >> >>Enabling sqlite by default has virtually no performance impact. Your >>binary is >>increased by roughly 100k and you initialize a dosen or so constants on >>startup. Comparatively speaking it is much 'nicer' then tokenizer (enabled by >>default) which initialized couple hundred constants at start up. > >I'm not approaching this from a performance standpoint, but from one where >statically compiled extensions slow the overall release process, make it >difficult for users to incrementally upgrade their extensions, and >generally contribute to bloat.
Most users don't care much about incrementally upgrading their extensions. Those that do it today are still the exception to the rule, and my estimate is that they'd stay the exception to the rule even when PECL becomes user-friendly, too (whether they're 0.1% or 5%, they're still a small minority). Letting the majority enjoy an out-of-the-box SQL solution far outweighs the need for this minority to add --without-sqllite. About slowing down the overall release process - I don't see why it should be related. It was discussed a lot of times, we can simply ship the latest version that's tagged stable of each extension that we choose to bundle. I never dug into the lean-and-mean approach, I still think that finding the features which are most important and enabling them by default is one of the reasons for PHP's tremendous success. Zeev

Zeev Suraski

23 years ago
At 17:46 24/06/2003, Marco Tabini wrote:
>Why not disable all extensions by default and add a configuration >utility that is launched before compilation--sort-of like the Linux >kernel?
We had one of those once, it was so popular that nobody even said anything when we removed it :) Zeev

Andi Gutmans

23 years ago
At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote:
> SQLite should become as pervasive as the session extension. > It is really a killer feature.
I think this was well put. It seems there is "almost" a consensus that bundling and enabling sqlite by default is a big advantage for PHP and its users. I agree that in many cases it will replace fopen() in a much sexier and easier manner. By the way, I have had lots of people talking to me about how to save their data while not having access to a DB server (usually people with personal or small sites). Sqlite is obviously the solution. Andi

Edin Kadribasic

23 years ago
> At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote: > > SQLite should become as pervasive as the session extension. > > It is really a killer feature. > > I think this was well put. It seems there is "almost" a consensus that > bundling and enabling sqlite by default is a big advantage for PHP and its > users. I agree that in many cases it will replace fopen() in a much sexier > and easier manner.
So the only question remains when to bundle it? I would like to see it bundled as soon as possible even in the 4.3.x series. Any thoughts on that? Edin

Rasmus Lerdorf

23 years ago
On Tue, 24 Jun 2003, Edin Kadribasic wrote:
> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote: > > > SQLite should become as pervasive as the session extension. > > > It is really a killer feature. > > > > I think this was well put. It seems there is "almost" a consensus that > > bundling and enabling sqlite by default is a big advantage for PHP and its > > users. I agree that in many cases it will replace fopen() in a much sexier > > and easier manner. > > So the only question remains when to bundle it? I would like to see it > bundled as soon as possible even in the 4.3.x series. Any thoughts on that?
It doesn't belong in 4.3. 4.3 is a release branch. Bug fixes only. I still think we need a 4.x dev branch to start the process of helping users towards the PHP 5 goal by doing things like bundling sqlite and adding some of the non PHP5-specific changes and features that they will come to rely on when they get to 5. -Rasmus

(Marcus Börger)

23 years ago
Hello Rasmus, Wednesday, June 25, 2003, 1:45:48 AM, you wrote: RL> On Tue, 24 Jun 2003, Edin Kadribasic wrote:
>> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote: >> > > SQLite should become as pervasive as the session extension. >> > > It is really a killer feature. >> > >> > I think this was well put. It seems there is "almost" a consensus that >> > bundling and enabling sqlite by default is a big advantage for PHP and its >> > users. I agree that in many cases it will replace fopen() in a much sexier >> > and easier manner. >> >> So the only question remains when to bundle it? I would like to see it >> bundled as soon as possible even in the 4.3.x series. Any thoughts on that?
RL> It doesn't belong in 4.3. 4.3 is a release branch. Bug fixes only. I RL> still think we need a 4.x dev branch to start the process of helping users RL> towards the PHP 5 goal by doing things like bundling sqlite and adding RL> some of the non PHP5-specific changes and features that they will come to RL> rely on when they get to 5. As one of the developers of the extension in question i can only agree. It does not belong in 4.3.x. And the more time passes, the more development happens i more and more tend to agree to 4.4, too. But anyway the counter part of doing this would be a delay in 5.0 release.
-- Best regards, Marcus mailto:helly@php.net

Rasmus Lerdorf

23 years ago
On Wed, 25 Jun 2003, Marcus Börger wrote:
> RL> On Tue, 24 Jun 2003, Edin Kadribasic wrote: > >> > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote: > >> > > SQLite should become as pervasive as the session extension. > >> > > It is really a killer feature. > >> > > >> > I think this was well put. It seems there is "almost" a consensus that > >> > bundling and enabling sqlite by default is a big advantage for PHP and its > >> > users. I agree that in many cases it will replace fopen() in a much sexier > >> > and easier manner. > >> > >> So the only question remains when to bundle it? I would like to see it > >> bundled as soon as possible even in the 4.3.x series. Any thoughts on that? > > RL> It doesn't belong in 4.3. 4.3 is a release branch. Bug fixes only. I > RL> still think we need a 4.x dev branch to start the process of helping users > RL> towards the PHP 5 goal by doing things like bundling sqlite and adding > RL> some of the non PHP5-specific changes and features that they will come to > RL> rely on when they get to 5. > > As one of the developers of the extension in question i can only agree. It > does not belong in 4.3.x. > > And the more time passes, the more development happens i more and more tend to > agree to 4.4, too. But anyway the counter part of doing this would be a delay > in 5.0 release.
I don't think so. The argument against it in the past was centered on the developers. Keeping a dev branch on 4.x distracted developers from working on 5. I think we are past that. People are clearly working on 5 and it is gaining momentum. What we need to look at now is migration of existing code from 4 to 5. There are things we can do in the 4.x codebase to make the eventual migration to 5 easier and less drastic and I don't think that will take away from 5.x development substantially. It will affect it a little bit, but mostly that effort will mean less pain later on when we finally do release 5. -Rasmus

Zeev Suraski

23 years ago
At 02:45 25/06/2003, Rasmus Lerdorf wrote:
>On Tue, 24 Jun 2003, Edin Kadribasic wrote: > > > At 04:32 PM 6/24/2003 +0200, Sascha Schumann wrote: > > > > SQLite should become as pervasive as the session extension. > > > > It is really a killer feature. > > > > > > I think this was well put. It seems there is "almost" a consensus that > > > bundling and enabling sqlite by default is a big advantage for PHP > and its > > > users. I agree that in many cases it will replace fopen() in a much > sexier > > > and easier manner. > > > > So the only question remains when to bundle it? I would like to see it > > bundled as soon as possible even in the 4.3.x series. Any thoughts on that? > >It doesn't belong in 4.3. 4.3 is a release branch. Bug fixes only. I >still think we need a 4.x dev branch to start the process of helping users >towards the PHP 5 goal by doing things like bundling sqlite and adding >some of the non PHP5-specific changes and features that they will come to >rely on when they get to 5.
-1 from me. We need everyone to concentrate on 5 if we want it to happen on time. With a beta coming out in less than a week, we shouldn't be splitting our power. Zeev

Andi Gutmans

23 years ago
Do we have documentation for the sqlite extension? Andi

Derick Rethans

23 years ago
On Tue, 24 Jun 2003, Andi Gutmans wrote:
> Do we have documentation for the sqlite extension?
I just send you a link by private email. (The url points to a test site for the livedocs, which is not ready for public). Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Wez Furlong

23 years ago
[To the list] You can also find the xml sources for the documentation in the CVS repository under phpdoc/en/reference/sqlite --Wez. ----- Original Message ----- From: "Derick Rethans" <derick@php.net> To: "Andi Gutmans" <andi@zend.com> Cc: <internals@lists.php.net> Sent: Tuesday, June 24, 2003 9:39 PM Subject: Re: [PHP-DEV] sqlite documentation

(Marcus Börger)

23 years ago
Hello Andi, Tuesday, June 24, 2003, 11:41:17 PM, you wrote: AG> Do we have documentation for the sqlite extension? We have :-) Thanks to Johann and Wez. And then there is of course the sqlite homepage which describes the sql dialect.
-- Best regards, Marcus mailto:helly@php.net

Sterling Hughes

23 years ago
On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote:
> Do we have documentation for the sqlite extension?
yep... Not sure if its on php.net, but its written and committed. Used to be available at http://docs.php.net/, but that's having problems at the moment. -Sterling
> > Andi
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

Ken Tossell

23 years ago
On Tue, 24 Jun 2003, Sterling Hughes wrote:
> On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: > > Do we have documentation for the sqlite extension? > > yep... Not sure if its on php.net, but its written and committed. Used > to be available at http://docs.php.net/, but that's having problems at > the moment.
Heh. Sqlite undefined. Beautiful.

Andi Gutmans

23 years ago
At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote:
>On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: > > Do we have documentation for the sqlite extension? > >yep... Not sure if its on php.net, but its written and committed. Used >to be available at http://docs.php.net/, but that's having problems at >the moment.
Thanks to both you and Derick :) Andi

Derick Rethans

23 years ago
On Tue, 24 Jun 2003, Andi Gutmans wrote:
> At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote: > >On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: > > > Do we have documentation for the sqlite extension? > > > >yep... Not sure if its on php.net, but its written and committed. Used > >to be available at http://docs.php.net/, but that's having problems at > >the moment. > > Thanks to both you and Derick :)
Atleast my URL works ;) Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Mike Robinson

23 years ago
Andi Gutmans wrote:
> At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote: > >On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: > > > Do we have documentation for the sqlite extension? > > > >yep... Not sure if its on php.net, but its written and committed. Used > >to be available at http://docs.php.net/, but that's having problems at > >the moment. > > Thanks to both you and Derick :)
Yes, absolutely outstanding, as usual. IMHO this is an _awesome_ addition to php. Well done. Best Regards Mike Robinson

Sterling Hughes

23 years ago
Just to clarify: Livedocs is a wez, derick and ilia thing. Sqlite is a wez, marcus, tal thing. I'm just an annoying cheerleader :) -Sterling On Tue, 2003-06-24 at 18:52, Mike Robinson wrote:
> Andi Gutmans wrote: > > > At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote: > > >On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: > > > > Do we have documentation for the sqlite extension? > > > > > >yep... Not sure if its on php.net, but its written and committed. Used > > >to be available at http://docs.php.net/, but that's having problems at > > >the moment. > > > > Thanks to both you and Derick :) > > Yes, absolutely outstanding, as usual. > IMHO this is an _awesome_ addition to php. Well done. > > Best Regards > Mike Robinson
-- "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." - Linus Torvalds

Rasmus Lerdorf

23 years ago
One of the main reasons PHP has reached the popularity it has today is because it was mindnumbingly easy to get started with it and you could do so many things with a default PHP installation. You can't twirl a wet cat without hitting servers with Gallery, PHP-Nuke, PHPBB or one of the other dozen or so pervasive PHP applications and these applications would not have become so popular had PHP not had enough default functionality to allow someone to write these apps to work on a default PHP install. They also tend to be smart enough to detect advanced features and then make use of those to make the app function somewhat better. Having what is essentially an SQL-driver for flat files as a standard PHP feature is going to raise the bar for many of these applications that, like it or not, drive PHP usage. Gallery is a perfect example of this. Have you had a look at the code? Check out all the nasty flat file manipulation code in that thing. It's painful to read through all that. The primary reason the Gallery author did this was because he wanted to make sure Gallery would run everywhere on every shared server. And as a result the code is both messy and the app is nowhere near as good as it could be. So yes, while I agree with the general sentiment of moving more stuff to PECL, for fundamental things like PCRE, Session and now SQL-access to flat files, that make up the core of what makes PHP what it is, I think this should be bundled. PHP has never been just a scripting engine with some cool add-ons. PHP has always been the solution to the Web problem with even more bonus add-ons. And as I have said so many times, PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely functional and convenient solution. If you are looking for purity you are in the wrong boat. Get out now before you get hit by a wet cat! -Rasmus

Sterling Hughes

23 years ago
Yes, Rasmus hit the nail on the button!
> So yes, while I agree with the general sentiment of moving more stuff to > PECL, for fundamental things like PCRE, Session and now SQL-access to flat > files, that make up the core of what makes PHP what it is, I think this > should be bundled.
The two major problems I see with PHP code these days: a) They use flatfiles where SQL, or some form of ordered storage, would be beneficial. b) They use RDBM's where flatfiles, or dbm files would be more expedient (a weblog system, for example). SQLite fills the niche so perfectly, and in very few lines of code. Don't think of SQLite as a database server - that would be terrible to bundle with PHP. Think of SQLite as a next generation interface to flat files, fopen(), fread() and friends should only be used when interacting with other data sources, because SQLite makes everything so simple (and more efficient.) No more custom formats, no more worrying about file locking, paging, no more worrying about the most efficient way to get data out of a file, and save data into a file. SQLite handles all of this for you, providing a simple SQL interface for accessing that data. In order for SQLite to become a replacement for fopen(), it needs to be bundled. Available everywhere, and available for everyone. It really costs us nothing. -Sterling On Tue, 2003-06-24 at 10:57, Rasmus Lerdorf wrote:
> One of the main reasons PHP has reached the popularity it has today is > because it was mindnumbingly easy to get started with it and you could do > so many things with a default PHP installation. You can't twirl a wet cat > without hitting servers with Gallery, PHP-Nuke, PHPBB or one of the other > dozen or so pervasive PHP applications and these applications would not > have become so popular had PHP not had enough default functionality to > allow someone to write these apps to work on a default PHP install. They > also tend to be smart enough to detect advanced features and then make use > of those to make the app function somewhat better. > > Having what is essentially an SQL-driver for flat files as a standard PHP > feature is going to raise the bar for many of these applications that, > like it or not, drive PHP usage. Gallery is a perfect example of this. > Have you had a look at the code? Check out all the nasty flat file > manipulation code in that thing. It's painful to read through all that. > The primary reason the Gallery author did this was because he wanted to > make sure Gallery would run everywhere on every shared server. And as a > result the code is both messy and the app is nowhere near as good as it > could be. > > So yes, while I agree with the general sentiment of moving more stuff to > PECL, for fundamental things like PCRE, Session and now SQL-access to flat > files, that make up the core of what makes PHP what it is, I think this > should be bundled. PHP has never been just a scripting engine with some > cool add-ons. PHP has always been the solution to the Web problem with > even more bonus add-ons. And as I have said so many times, PHP is not > about purity in CS principles or architecture, it is about solving the > ugly web problem with an admittedly ugly, but extremely functional and > convenient solution. If you are looking for purity you are in the wrong > boat. Get out now before you get hit by a wet cat! > > -Rasmus
-- "Microsoft isn't evil, they just make really crappy operating systems." - Linus Torvalds

Dan Kalowsky

23 years ago
I don't think the question is bundling SQLite, as many of us really don't seem to mind that. Even I who am notorious for not liking bundling software won't argue with this one. I see it as a Good Thing for PHP as a whole. I'm not sure that it should be enabled by default though, which is an entirely different concept. On Tue, 24 Jun 2003, Sterling Hughes wrote:
> Yes, Rasmus hit the nail on the button! > > > So yes, while I agree with the general sentiment of moving more stuff to > > PECL, for fundamental things like PCRE, Session and now SQL-access to flat > > files, that make up the core of what makes PHP what it is, I think this > > should be bundled. > > > The two major problems I see with PHP code these days: > > a) They use flatfiles where SQL, or some form of ordered storage, would > be beneficial. > > b) They use RDBM's where flatfiles, or dbm files would be more expedient > (a weblog system, for example). > > SQLite fills the niche so perfectly, and in very few lines of code. > Don't think of SQLite as a database server - that would be terrible to > bundle with PHP. > > Think of SQLite as a next generation interface to flat files, fopen(), > fread() and friends should only be used when interacting with other data > sources, because SQLite makes everything so simple (and more > efficient.) No more custom formats, no more worrying about file > locking, paging, no more worrying about the most efficient way to get > data out of a file, and save data into a file. SQLite handles all of > this for you, providing a simple SQL interface for accessing that data. > > In order for SQLite to become a replacement for fopen(), it needs to be > bundled. Available everywhere, and available for everyone. It really > costs us nothing. > > -Sterling > > > On Tue, 2003-06-24 at 10:57, Rasmus Lerdorf wrote: > > One of the main reasons PHP has reached the popularity it has today is > > because it was mindnumbingly easy to get started with it and you could do > > so many things with a default PHP installation. You can't twirl a wet cat > > without hitting servers with Gallery, PHP-Nuke, PHPBB or one of the other > > dozen or so pervasive PHP applications and these applications would not > > have become so popular had PHP not had enough default functionality to > > allow someone to write these apps to work on a default PHP install. They > > also tend to be smart enough to detect advanced features and then make use > > of those to make the app function somewhat better. > > > > Having what is essentially an SQL-driver for flat files as a standard PHP > > feature is going to raise the bar for many of these applications that, > > like it or not, drive PHP usage. Gallery is a perfect example of this. > > Have you had a look at the code? Check out all the nasty flat file > > manipulation code in that thing. It's painful to read through all that. > > The primary reason the Gallery author did this was because he wanted to > > make sure Gallery would run everywhere on every shared server. And as a > > result the code is both messy and the app is nowhere near as good as it > > could be. > > > > So yes, while I agree with the general sentiment of moving more stuff to > > PECL, for fundamental things like PCRE, Session and now SQL-access to flat > > files, that make up the core of what makes PHP what it is, I think this > > should be bundled. PHP has never been just a scripting engine with some > > cool add-ons. PHP has always been the solution to the Web problem with > > even more bonus add-ons. And as I have said so many times, PHP is not > > about purity in CS principles or architecture, it is about solving the > > ugly web problem with an admittedly ugly, but extremely functional and > > convenient solution. If you are looking for purity you are in the wrong > > boat. Get out now before you get hit by a wet cat! > > > > -Rasmus >
>---------------------------------------------------------------<
Dan Kalowsky "I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin." dank-nom@aps-deadmime.org - "Streets of Philadelphia", kalowsky@php.net Bruce Springsteen

Shane Caraveo

23 years ago
After long amounts of reading +1 However, I'd like to see sqlite remain in PECL, and start using PECL the way it should be. That would be a good start. I think it would ease some minds, and point out whatever areas happen to still be *real* issues (if any). Shane

Ilia A.

23 years ago
On June 23, 2003 01:48 pm, Dan Kalowsky wrote:
> As always I'm against any enable by default thinking. > Why, oh why, are we making this wonderful configure script > completely useless?
In a perfect world nothing would be enabled by default and each user would enable just the extensions they wont. In reality however, most people use shared webhosts and have no control over PHP and in many cases web hosts will refuse to modify their PHP installation. The same webhosts (judging from my personal experience with at least 4-5 dosen hosting companies) usually rely on the default configuration options, with only non-default options being the ones relating to safe_mode. What this means if we disable MySQL by default, the stock php will no longer come with a built-in database support. This IMHO is very bad, since large number of php scripts require a database of some sort. Enabling by the extension by default would also accelerate it's addoption by distributable script authors, who won't have to worry about availability of the extension. I think we can all agree that MySQL's popularity with PHP is largely the result of it nearly always being avaliable. Ilia

(Marcus Börger)

23 years ago
Hello Sterling, Monday, June 23, 2003, 4:38:42 AM, you wrote: SH> Hey, SH> Unless anyone objects I'm going to enable the sqlite extension by SH> default for PHP5. The extension comes with the bundled sqlite library SH> which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), SH> and is a good alternative to using MySQL for small sites. SH> The sqlite library is licensed to the public domain and provides a SH> complete database solution in a small library - no server required. For SH> more information take a look at http://www.hwaci.com/sw/sqlite/. Enabling it by default offers a hell lot range of new applications and usage fields. And think of how easy it will be to give shared hoster the possibility to give their users the strength of a real database without having to care about disk spaces and user rights and bla bla bla in a shared DBMS. And then not enabling it by default would result in no shared hoster using it. So you might guess i'm all for enabling by default.
-- Best regards, Marcus mailto:helly@php.net

Jani Taskinen

23 years ago
Where/when it was decided to be included in the main distribution in the first place? --Jani On 22 Jun 2003, Sterling Hughes wrote:

Jani Taskinen

23 years ago
Nevermind, I was just wondering about the PHP_4_3 branch having it too, but that's propably just temporary thing. --Jani On Tue, 24 Jun 2003, Jani Taskinen wrote:
> > Where/when it was decided to be included in the main > distribution in the first place? > > --Jani > > >On 22 Jun 2003, Sterling Hughes wrote: > >>Hey, >> >>Unless anyone objects I'm going to enable the sqlite extension by >>default for PHP5. The extension comes with the bundled sqlite library >>which is 1.5mb in total (cd ext/sqlite/libsqlite/src/; du -ch *.c *.h), >>and is a good alternative to using MySQL for small sites. >> >>The sqlite library is licensed to the public domain and provides a >>complete database solution in a small library - no server required. For >>more information take a look at http://www.hwaci.com/sw/sqlite/. >> >>-Sterling > > >
-- https://www.paypal.com/xclick/business=sniper@php.net&no_note=1&tax=0&currency_code=EUR

Rasmus Lerdorf

23 years ago
Yeah, I was surprised to see it on the 4_3 branch as well. I don't think it should be there. I would like to suggest a 4.4 release at some point after we get 4.3.3 out the door with the aim being to bridge users from 4.x to 5.x. It would look as much like 5.x as is feasible, but be based on the 4.x codebase so people will have an easier migration path and we spread the pain out a little bit. And sqlite would fit into such a release quite well. -Rasmus On Tue, 24 Jun 2003, Jani Taskinen wrote: