Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender)
Message-ID: <52E9A631.5050808@sugarcrm.com>
Date: Wed, 29 Jan 2014 17:09:05 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com> <CAGa2bXZTMDQffTNF5G_N9s9qqzkD0188+jAZ5JAqoraxbKwjHQ@mail.gmail.com>
In-Reply-To: <CAGa2bXZTMDQffTNF5G_N9s9qqzkD0188+jAZ5JAqoraxbKwjHQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
From: smalyshev@sugarcrm.com (Stas Malyshev)

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