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

From: Date: Tue, 18 Mar 2014 10:58:44 +0000
Subject: Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi,


>> 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

I don't think 5.6 is looked at as a minor version. Features have been
added, changed, deprecated and removed in previous 5.x releases.

>> 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

Exacly why I wrote an RFC, except Yasuo already explained that current
workflows (speaking of userland handlers) are not affected and BC is
maintaned.

> 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 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?

> 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.

Cheers,
Andrey.


Thread (34 messages)

« previous php.internals (#73266) next »