Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory

From: Date: Thu, 30 Jan 2014 01:09:05 +0000
Subject: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi!

> There are 6 vote options now. It would be too much. 
> Does anyone mind if I make the RFC a single vote?
> Or should I separate Proposal 2 (minimize_lock)?

6 options seems too much. 0 shouln't even be a vote - if people want
specific options, then ipso facto they want them introduced, and
parameter is a way to do it, if none is accepted - there's no reason to
introduce the parameter. I would rather make it part of the whole
proposal and propose both INI value and session_start options (with the
latter overriding the former).

Proposal 5 seems to have nothing to do with the rest. So it probably
needs to be split out.

I'd just leave it as two proposals (this is my personal preference):

1. Options & read_only + lazy_write (these ones seem to be least
controversial ones and don't seem to have any negative implications)
2. lazy_destroy
3. minimize_lock if you really want it though I still think it is
dangerous and is not needed if read_only and lazy-write exist and if you
still need it you're doing sessions wrong. But if you really think
there's a case then let's put it as separate one.

So we'd have 2 or 3 options, which I think is the max for vote to be
manageable.

Some more things:
- session_unlock - I don't see how it's different from session_abort.
What's the need for it?
- session_module_feature - what is the use case for it? I'm not sure I
understand why anybody would use it. Especially if outputs would be
non-machine-friendly as "Partially Supported" - what would you do with
that? What Partially means here?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


Thread (42 messages)

« previous php.internals (#71766) next »