Am 22.05.2013 12:19, schrieb Marcus Don:
where did i say that i have a performance problem?
I just assumed that was the reason you felt so strongly about it
you do not need to assume anything you simply need to follow the thread
i feel so strongly about it because it fucks up since 4 months on machines where any other web-app is running without the smallest issue which is only caused by custom session handlers
the called reasons where security and scalability which is *wrong* on most setups, in case of security the opposite is true, a sane setup does *not allow* a script running in the context of user A access session-data of user B which is true with the php-handler and open_basedir but *completly wrong* in case of session data in the database shared by all users
and the performance part is also *not* true or irrelevant for most setups and scalability should never be solved on the application layer, only few need shared sessions over different servers and they who need should know how to achieve this or at least it has not to be deafult for all setups
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Tue, 21 May 2013 08:59:05 +0200 Von: A.L.E.C alec@alec.pl An: dev@lists.roundcube.net
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Mon, 20 May 2013 16:39:51 +0200 Von: Reindl Harald h.reindl@thelounge.net
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting **