> Am 07.12.2016 um 21:07 schrieb Yasuo Ohgaki <yohg...@ohgaki.net>:
> 
> Hi Tony,
> 
> On Wed, Dec 7, 2016 at 7:17 PM, Tony Marston <tonymars...@hotmail.com 
> <mailto:tonymars...@hotmail.com>> wrote:
>> "Yasuo Ohgaki"  wrote in message
>> news:caga2bxyax05jbjavyxfsjyy6xia+4u14npfgywscl4aoofq...@mail.gmail.com...
>>> 
>>> 
>>> Hi Marco,
>>> 
>>> Thank you for explaining the reason why!
>>> 
>>> On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta <ocram...@gmail.com> wrote:
>>>> 
>>>> I voted "no" because I don't see any advantage over using a custom
>>>> session
>>>> save handler, besides adding more API that partially covers custom
>>>> session
>>>> save handlers.
>>> 
>>> 
>>> You mean current OO custom save handler, I suppose.
>>> 
>>> Firstly, current OO custom save handler design (use of previously used
>>> internal save handler as its base class) is not good. Overriding
>>> open()/close()/etc are useless, moreover harmful. Number of bugs
>>> proved it is not good.
>> 
>> 
>> I have been using session_set_save_handler() since 2002 to store all session
>> data in a database, and I have never encountered any problems. Why is it
>> "not good"? What bugs are there?
> 
> It works if it is used correctly. However, we've got number of bug
> reports for abuse/misuse cases. Refer to bugs.php.net <http://bugs.php.net/> 
> for details.
> 
>> 
>> I do not see the point in this RFC.
> 
> Did you read the RFC?
> It enables to write serializer by PHP script, clean and simple. It
> cannot be done by save handler.

We can just directly read from $_SESSION (in write) and use session_encode() 
(for returning on read()) as a workaround.
It isn't the cleanest way, but it works.

I appreciate a cleaner way, but it really should (see the last mail) cover 
everything, including the need to store to different locations.

> Besides, the reason why we don't have user defined serializer is
> "register_globals", the reason why we have problematic base class for
> OO API save handler is "register_globals".  We should get rid of
> obsolete features at some point also.

Could you please that explain further?
Also cleaning up obsolete features would be nice, rather sooner than later.

Bob

> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net <mailto:yohg...@ohgaki.net>
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php 
> <http://www.php.net/unsub.php>

Reply via email to