Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions

On Wed, Mar 19, 2014 at 1:04 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi all, > > On Tue, Mar 18, 2014 at 7:58 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> Exacly why I wrote an RFC, except Yasuo already explained that current >> workflows (speaking of userland handlers) are not affected and BC is >> maintaned. > > > I found issue with object based save handlers, but it was solved without any > BC. > > I also added createSid() method support. If both create_sid() and > createSid() exists, > createSid() is used. I thought this was currently in discussion, and in a separate thread? >> > How about making it a INI option? It makes session_start() option >> > handling >> > code >> > a little simpler. It's not mandatory, though. >> >> +1 from me, if it is to be kept as an option. > > > I'm about to modify patch to make it INI. No objections for this? Well, I said 'if' we keep it as an option at all. I'd rather update the RFC to propose it as non-optional behavior since there are no downsides from it, as I understand. >> > I think we are better to have another SessionHandler object that support >> > new >> > APIs. >> > We can handle create_sid() method rename with new object also. We may >> > keep >> > current implementation undocumented and may document it new one >> > (createSid()) only. >> > I will name it "SessionUpdateTimestampHandler". If anyone has >> > suggestions, >> > I would appreciate it. >> >> I object, although it should've been called SessionFilesHandler in the >> first place, that way we could also have SessionMemcacheHandler, >> SessionWhateverHandler - way nicer than it currently is, but again - >> not the point of this discussion. > > > I removed new object. It's not needed anymore, since I prevented bogus > methods > registration. Bogus methods? I wrote this RFC because it was completely unclear how certain situations would be handled ... now this is also unclear. :) I sent you a private e-mail earlier today, perhaps you could explain me that in a reply to it so that we don't spam the list. Cheers, Andrey.