Hi Stas,
Thank you for the comment on github.
On Tue, Mar 18, 2014 at 2:45 PM, Stas Malyshev <[email protected]>wrote:
> > I agree.
> > If nobody objects, I'll remove the option. Please send mail ASAP!
>
> I think defaults should not change in minor version, unless there's a
> very good reason for it, and here it's not a very good reason. Session
> module is very sensitive, and doing changes in it should be very
> conservative to not break people's workflows. While new behavior serves
> an important use case, it may not be everybody's use case, especially
> with all handlers. Thus, I would rather have it an option - exactly as
> voted. When we move into PHP 6, where certain major changes are
> expected, we can change the defaults. But I think introducing such
> change in a minor version is unnecessary risk.
> And also it subverts RFC process as it's not what the vote was for, and
> it's a substantial change - default behavior change (means, everybody
> affected) instead of option (means, only people using the option affected
No problem.
How about making it a INI option? It makes session_start() option handling
code
a little simpler. It's not mandatory, though.
> > When is the beta due? I made PR so that RMs can merge it.
>
> I'd recommend waiting for it to be thoroughly reviewed before merging. I
> myself will try to take a look in coming days, as my schedule allows,
> but it may take time to polish some things. Sessions are very sensitive
> area, so we need to be very careful.
I agree. Even for beta, we should be careful.
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)
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.
Regards,
--
Yasuo Ohgaki
[email protected]