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

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. Since user does not have to user Session module defined interface, user may omit create_sid() definition. Even without createSid() or my patch, current behavior is some what confusing. I'll document them all later. > No problem. > > > > 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? > > > I found issue with object based user save handler. Unlike procedural user > > save handlers, > > object based user save handler uses previously used save handler as it's > > base class (some what) > > Isn't that the whole point of it, that you can overload only specific > parts of the default one? > It's solved. I should have try to prevent defining bogus handlers. i.e. Existing C written save handlers do not support new API and object based save handler try to call it if user hasn't define method for these. > > > 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. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net