Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
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)