Generic session handler

[gregmac]

Write sessions as a generic API, so different backends can be used (may make sense to write the BF Session API to just be a frontend to the PHP native sessions, and use PHP's session handlers).

This way, backends for native PHP files-based sessions, fully db-based sessions, and CI-style cookie-based sessions could all be used with the same API, simply by changing a config variable.

[gregmac]

Should be backwards compatible with CI's session API, but also add some methods that make it easier to use (like set($var,$value)).

It should also probably have "flash" variables .. eg, variables that you set once, and that work for the next page load (or possibly until you read them) and then are destroyed.

[Tido]

See SessionAPI for the BlueFlame? Session API discussion. I like the idea of having a config item set what "session driver" you'll be using (be it CI/Simple Cookie, Native Session, or DB based session). Then the session class loads the driver it needs (and none of the others to save resources) and applies the API to it.

Another thing to consider is to employ a 'hooks'-style method to do session reads and session writes at the beginning and end of the application process. So BF starts, if session is enabled it loads the session and its driver, it gets the session info, then the application and all it's controllers run, and at the end the session class writes it's changes to the session. This will have better performance than the current session libraries.

[Tido]

Bah Trac didn't link it. SessionAPI?

[Shadowhand]

This is complete in Kohana 2.0. The session API is completely separated from the driver, and uses session_set_save_handler(), so that $_SESSION works as expected.