PHP 5.3 compatibility?

[mindplay-dk]

It looks like you've been refactoring for PHP 5.3 compatibility?

If so, please note that session_set_save_handler does not support SessionHandlerInterface before 5.4.

[armatronic]

I've played with this and the only blocker for PHP 5.3 support is the non-existence of the session_status() method, and there being no good way to tell if a session has been started but then closed.

The only way I found to reliably tell if a session has been closed is to use the deprecated session_is_registered() and session_register() methods.

    public function start() {
        $started = session_start();
        if ($started) {
            // I don't want to raise a deprecated error message
            $errorlevel = error_reporting(error_reporting() & ~E_DEPRECATED);
            session_register('some_phantom_session_var');
            error_reporting($errorlevel);
        }
        return $started;
    }

    public function getStatus() {
        $errorlevel = error_reporting(error_reporting() & ~E_DEPRECATED);
        $result     = session_is_registered('some_phantom_session_var');
        error_reporting($errorlevel);
        return $result ? 
            2: // PHP_SESSION_ACTIVE
            1; // PHP_SESSION_NONE
    }

[harikt]

I don't think we need to go for deprecated methods.

So we will look forward how to make things better.

[armatronic]

Fair enough - the code I supplied is pretty ugly (not only with the deprecated methods but with the phantom session var) but it's the only thing I know of that works in 5.3 when a session has been closed.

[armatronic]

I found what I think is a better method (doesn't use deprecated methods or the phantom session var) here - http://stackoverflow.com/questions/3788369/how-to-tell-if-a-session-is-active/7656468#7656468

[pmjones]

The issue is related to 5.3 compatibility, and I think we have achieved that with #10. PHP 5.3 compat is a goal for v2 of this package, so we'll stay on top of it. Thanks @mindplay-dk and @armatronic for paying close attention here.

[harikt]

I like the session to be 5.4+ with the usage of the SessionInterface . I am not sure how many of us will be using 5.3. As upgrading from 5.3 to 5.4 will not break anything, people can upgrade soon.

[mindplay-dk]

I like the session to be 5.4+ with the usage of the SessionInterface

There is no functional difference - implementing and registering the old way or the new way, yields identical results. Since this stuff is encapsulated, there is no compelling functional reason to sacrifice BC - it only affects the library internally...

[harikt]

Hey @mindplay-dk ,

I may be ignorant . According to my knowledge the session_set_save_handler have different signature in 5.3 and 5.4 .

 bool session_set_save_handler ( callable $open , callable $close , callable $read , callable $write , callable $destroy , callable $gc )

Since PHP 5.4 it is possible to register the following prototype:

bool session_set_save_handler ( SessionHandlerInterface $sessionhandler [, bool register_shutdown = true ] )

Or will it still work the same way in 5.4 . And I am not seeing an interface in ours which we can add a save handler to database or probably something to redis or a different storage.

May be I am missing something.

[mindplay-dk]

@harikt yes, it has an alternative signature and the added SessionHandlerInterface in 5.4 - if you examine the callbacks vs the methods of the interface, you can see they're identical. In other words, the shape of the API is different - but the functionality offered by the two APIs is, for all intents and purposes, identical.

The only real difference is you can have an actual object of a class implementing an interface in 5.4, which means you can have an object carrying state - but again, you can share state between closures by other means, so this only really changes the shape of the code, it doesn't affect it's capabilities.

At least as far as I can figure :-)