Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:3132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <106101c3402b$adab4540$0702a8c0@TITAN>
To: "Sterling Hughes" <sterling@bumblebury.com>
Cc: <internals@lists.php.net>, "Sascha Schumann" <sascha@schumann.cx>
References: <1057087738.1360.216.camel@hasele> <100e01c3400b$0de2a140$0702a8c0@TITAN> <1057088982.4160.238.camel@hasele>
Date: Wed, 2 Jul 2003 00:51:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Removing SQLite sessions from the defaultdistribution
From: wez@thebrainroom.com ("Wez Furlong")

What is the point of publishing a benchmark if you are not comparing an SQL
data store with an SQL data store?

> I will commit my fixes, if the decision is to bundle sqlite.  Or someone
> is interested in trying it out in the interim.

Commit it.

> Also note, this would mean that all
> shared hosts go to a single sqlite database, instead of a directory.
> One site may not get a lot of hits, but an entire shared host would.
> This directive is per-php ini, and has to be.

Huh?
Thats bullshit.
session.save_path allows you to configure the database per virtual host.
There is no restriction that forces an entire server to use the same dir.

Each server should use a seperate save path anyway (or have you never had
problems with session collisions between vhosts?).

> Why would you get your own server to serve one website if performance
> wasn't important?  You wouldn't.  Further, Why would you use SQLite
> instead of the files based system?  Give me a problem this solves.

This is also pure excrement.

> >
> > Yes, "enterprise" sites would be stupid to use sqlite for session
storage,
> > but then, enterprise sites probably won't be using sqlite at all.
>
> I'm not talking about enterprise sites.  I didn't mention that once in
> fact.  I'm talking about your every day average people, using php on a
> shared host.

and everyday users cluster their sessions...

>  They wouldn't use sqlite, because it requires that every
> person on the shared host use sqlite (and I doubt anyone would use
> per-dir).

again...

> In general database backends make no sense for sessions support, unless
> you want to integrate into a pre-existing architecture, or you want to
> cluster (and even then its iffy).  The Sqlite sessions supports allows
> you to do neither of these things.  Its not easier to use, its a 300%
> slowdown, and its not nearly as "safe" in shared environments (you can't
> have different users for different sessions safely.)
>
> So why add it?

Because it is a single .c file logically grouped with the rest of the
library that we bundle.

If you hate it so much, lets just unbundle the whole sqlite extension.

--Wez.