Re: [RFC][VOTE] User defined session serializer
| From: | Bob Weinand | Date: | Wed, 07 Dec 2016 22:40:17 +0000 |
| Subject: | Re: [RFC][VOTE] User defined session serializer | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97333@lists.php.net to get a copy of this message | ||
> Am 07.12.2016 um 21:49 schrieb Yasuo Ohgaki <yohgaki@ohgaki.net>:
>
> Hi voters,
>
> Following people are vote against this RFC for now.
>
> bwoebi (bwoebi)
> danack (danack)
> hywan (hywan)
> leigh (leigh)
> levim (levim)
> nikic (nikic)
> ocramius (ocramius)
> peehaa (peehaa)
> ryat (ryat)
>
> I suppose bwoebi and levim vote against due to error and exception
> usage. Thank you for feedback, Levi and Bob.
>
> How many of you vote "no" because of error and exception issue?
>
> IMHO. Exception in session module is out of scope of RFC, mixing
> error and exception in a module is confusing and inconsistent. Session
> module is not language engine, so I'm not 100% sure if we should use
> TypeError exception for normal module's invalid return type. However,
> I don't mind much to use exception if many of us insist.
> (BTW, "interface" parameter issue is out of scope this RFC also. It
> should be addressed by OO API cleanup RFC consistently. I'm trying to
> resolve issues one by one.)
>
> I wonder how many of you understand this RFC is really a
> "register_globals" legacy cleanup? Do you really think we should keep
> "register_globals" legacy because of irrelevant issue?
>
> Thank you for feedback!
> Unless there are feedbacks, nobody cannot figure out what's the reason
> behind for "no" votes.
>
> Regards,
>
> --
> Yasuo Ohgaki
Exceptions is one thing.
That's why I initially voted no.
Though thinking more about it, I still do not see the need.
session_set_save_handler() ultimately can just do the job completely.
Encryption? save_handler can do that.
Saving to somewhere else? It can do that.
Note that your RFC is not a replacement. Especially the last thing, saving to somewhere else, which
isn't a file, cannot be prevented without it.
If there were:
save(string $uuid, array $data)
read(string $uuid): array $data
That'd make much more sense. Having to do flock() + file_get_contents() / file_put_contents()
yourself to sys_get_temp_dir()."/$uuid" is not a problem in case you want to save it
yourself.
Perhaps we should provide session_default_write(string $data)/session_default_read(string $data). I
do not care too much.
And how is that related to register_globals?!
If this RFC were a proper replacement with also a proposed deprecation plan (e.g. in 7.4 (or 8.0)
whatever comes first), that'd be a plus too. But currently it looks like we're heading to
just have yet another separate system for sessions.
Bob