I like this idea. I think we have another issue about splitting the component and create a new one for sessions.

I proposed that already in #6840. The idea that sessions are not part of the HTTP specification was exactly the argument I used when discussing symfony sessions with @znerol from drupal a few weeks ago. So I'm 👍 for making a new component.

@fabpot I think it would also be best to start this new session component from scratch and deprecate the old one. This way we can fix all the design issues. Fixing all these issues with the current architecture is almost impossible without breaking bc. I would be willing to take the lead for that. It's just a matter of finding the time/resources.

@Tobion I agree with you and if you can take the lead, that would be wonderful. Creating a new component also mean that it can be part of 2.7, no need to wait for 3.0.

When rewriting the session component from scratch, it would be great if it drop support for PHP < 5.4.

http://scache.nanona.fi/

👍

@znerol Drop support for PHP<5.4 would imply, that it cannot go into 2.7

@mvrhov we cannot force the usage of scache (it would severely limit the possibility to use Symfony if we introduce a hard dependency to this extension). However, it might be a good idea to support scache as a storage in the new component.

@stof: I know that addidg scache as a default mechanism would limit the new symfony adoption. I've added the link because I find the ideas behind interesting and well thought and it solves many propblems people are having today with sessions. This is Something that should be supported by php out of the box. @jpauli

@kingcrunch even if it is implemented as a new component and the existing session support would be left in place (marked as deprecated)? Projects updating to 2.7 would still be free to continue using the old one (compatible to ancient PHP) without suffering BC issues. New projects starting with 2.7 simply could go with the new component which is free of the compatibility shims and legacy cruft.

i am just thinking about the interface of the sessionHandler, would you prefer using optimiticLocking or try to implement a global locking? - and why?

interface SessionHandlerInterface {

  public function supports($sessionId);

  public function read($key, $default = null);

  public function writeWithOptimisticLock($key, $currentValue, $newValue);

}

👍 I think a new component for sessions would be the best way.

@JHGitty I agree. E.g. Laravel already did it.

What do you think about it? I might try to decouple it.

Related: #10557

@fabpot Status Bump? This issue seems stale.