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