Re: Session management module - thoughts
| From: | Jim Winstead | Date: | Sat, 29 May 1999 00:16:52 +0000 |
| Subject: | Re: Session management module - thoughts | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-6220@lists.php.net to get a copy of this message | ||
On May 29, Zeev Suraski wrote:
> I saw the session start function that required at least one argument and
> the session variable registration that required a session handle argument,
> and didn't like what I saw. I'm not on some power trip on who prorposed
> what, I really think it's in our best interest to implement something
> simple because (a) you rarely need something complex, if you do, you're
> probably clueful enough to use phplib (b) it's quicker to implement simple
> APIs.
We're just kicking around ideas to make sure we don't paint ourselves
into a corner with a too-simple API. It would be a shame if in six
months the advice given to people on the PHP mailing list was "well,
to do that you have to use this third-party stuff instead of the
built-in support, and they don't look at all like each other"
instead of "well, just do this in addition to the built-in support,
and it works great!"
I agree that having session_begin() return an identifier and
requiring it in session_register(), et al, is a bad idea. So make
it return one and let it be optional in session_register, much
like it is for connection ids in mysql_*(). This seems like a
very cheap addition to the API for the flexibility it offers.
(Here's a problem I'm trying to avoid: if the session support isn't
flexible enough to satisfy as many users as possible, it will get
very little support from PHP "power-users" and other developers,
and will end up being more of a burden than a benefit.)
> > A path pointer in the php.ini file isn't good enough, as some people
> > (and I'm thinking of those using a PHP installation that is provider-
> > installed) don't have access to that form of configuration, so we
> > need to expose this at least as a function to precede the session_being
> > call.
>
> In fact, I don't think that users should have anything to do with this.
> If I'm an ISP, why would my users have to specify where they save their
> session information? I do think it's the ISPs job to configure it.
And they won't. We should provide the hook so that people can do
the right thing if their ISP doesn't. Should we require everyone to
use it? No. Would it be great if every ISP configured it so it
worked for users out of the box? Yes.
> > Anyone know how ASP deals with it?
>
> While I don't know how ASP deals with it, I can think of a vague approach
> towards a solution. We can probably spawn a thread (under Win32) or a
> process (under UNIX) that'll simply clean up old sessions, while sleeping
> most of the time. We can kill this thread/process at the server shutdown.
That's also not going to be acceptable for some ISPs. Many strictly
prohibit their users from running their own daemons. I think we
need to provide the fallback of doing the cleanup on a per-request
basis (perhaps regulated by some element of randomness as PHPLIB's
apparently is).
Jim
--
PHP Development Mailing List http://www.php.net/
To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net
For help: php-dev-help@lists.php.net