Hi Bob, Thank you for feedback!
On Thu, Dec 8, 2016 at 7:44 AM, Bob Weinand <bobw...@hotmail.com> wrote: > 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. It's been years ago, so I barely remember the current OO save handler API implementation discussion. If anyone remember the discussion, please correct me if I'm wrong. IIRC, when current OO API was introduced, user defined serializer was considered also. However, serializers had to consider register_globals compliance that registers session variable as a global vars via session_register(). Unlike $_SESSION/$HTTP_SESSION_VARS, session_register()ed global vars are marked as session variable even when they are undefined. Serializers (php and php_binary) saves these undefined global session vars with PS_UNDEF_MAKER/PS_BIN_UNDEF and restores them. i.e. Session variables are designed to work like other GPC "register_global"ed vars at first. Note: I recently noticed that there are remained codes for global session var support, so I created PR to remove them. https://github.com/php/php-src/pull/2233 Because of PS_UNDEF_MARKER(undefined global session vars), it was too easy for users to implement broken serializers at that time. Instead of exposing serializer submodule to users, OO API was made to override session read()/write() for encryption/etc. (I completely forgot about this, but I remembered this when I discussed about this with Stas about a year(?) ago) There were discussion about overriding open()/close(). Broken open()/close() override would cause problems, but overriding was allowed for consistency sake, open()/close() override is allowed because it might be useful for some cases. IMO, this design was reasonable choice at that time. Thankfully, we removed register_globals support altogether. The choice became obsolete. i.e. We can use normal serialization like "php_serialize" serializer as well as JSON/XML/etc serialization. We can comply original session module design now, serializer submodule to convert/restore session data for saving/from retrieved data, save handlers submodule to save/retrieve session data from db. We may keep current OO API as long as users are using it, but I'll propose new/clean/complete OO API before 7.2. i.e. No base object and full method interface by a single interface definition - there are 3 interfaces now. BTW, the main RFC objective is to allow "User defined serializer" as RFC title states. Session data "encryption/validation/modification" is subproduct. Please note that users cannot write clean/efficient user defined serializer without this RFC. I hope I explained the background well. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
