Re: Re: Revert session_serializer_name(), session_gc()

From: Date: Thu, 13 Mar 2014 20:29:29 +0000
Subject: Re: Re: Revert session_serializer_name(), session_gc()
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.internals 
Request: Send a blank email to internals+get-73127@lists.php.net to get a copy of this message
On Thu, Mar 13, 2014 at 9:32 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Thu, Mar 13, 2014 at 7:36 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> > The _proper_ solution, would be to keep a timestamp stored with each >> > session. kind of a last-modified timestamp. (expiry does work off last >> > modification, right?). Anyhow, the trick is to check at session_start >> > whether that timestamp plus whatever session.expire is set at, already is in >> > the past - and when that happens, destroy the one session on storage and act >> > as if it hadn't been found. >> >> Such a timestamp already exists, you can't implement sessions without >> one because there would be no way to know when a session have expired. >> For the files handler, it's filemtime() (afaik) and the behavior that >> you described is probably already in use (I see no reason not to). > > > Time stamp exists. It's correct partially. > > The time stamp is not usable for HTTP session manager to manage session > properly. We may have new API that gets time stamp of session data, but it > would require large overhead. i.e. Need additional API call to get time > stamp = additional query to session storage. The overhead cannot be ignored. > > The proper way to get and set the time stamp is "get/set time stamp" when > "store/retrieve session data". This way, there would not be overhead. User > may implement in their script, but it's a session manager task to begin > with. > >> >> >> However, that's not in the scope of GC. > > > Managing time stamp is the main task of session GC, isn't it? Yasuo, you took 2 paragraphs that belong together and put them out of context ... >> However, while Yasuo seems to always be keen on creating RFCs >> immediately, I'd rather focus on the existing ones that are session >> related: > > > You are the one who said there should be RFCs ;) > There are RFCs because I'm trying to change existing behaviors rather than > simple bug fixes. > > > Anyway, this was discussion of committed patch. It has much higher priority > than not implemented RFC, I suppose. I still think there should be GC > function. Programmers should control GC and there should be session function > for it rather than INI tweak. Exactly, focus on current tasks is what I'm saying. In the timespan of 5 hours you asked me twice if I will write the RFC _and_ wrote it without even waiting for the reply. Let's stop this nonsense now and discuss more important stuff. :) Cheers, Andrey.

« previous php.internals (#73127) next »