Hi there! I have a similar library.

[weierophinney]

Hey. I have followed you on Github and, today, I noticed that you were working on this repo.
I had worked on somewhat similar library a few months back. It's called ps7-session.

It is not completely dependent on expressive. It's a php7 based session library with added support for interop middleware-based applications. Check this

I was wondering if we could talk about whether these two could complement each other. If using that library as a dependency is a good idea. I am open to moving it to zend organization if it's good enough for you people :D
Or, maybe, this library can take some ideas from my library.

The reason I created that library because I was trying to run an expressive based application with reactphp/http and $_SESSION was not usable. Running the expressive application with reactphp was actually experimental and won't make it to production(atleast for now). But, on the process, I was motivated enough to write that library.

Best Regards,
Your long-time fan and follower,
Ujjwal Ojha

---

Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1

[weierophinney]

I created this issue when the repo belonged to Matthew. So, anyone who is confused by the usage of "you", it's Matthew.

---

Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1 (comment)

[weierophinney]

No reply :/
The issue seems pointless now since version 1 is already released.
Closing!

---

Originally posted by @ojhaujjwal at zendframework/zend-expressive-session#1 (comment)

[weierophinney]

We released 0.1, not 1.0; we expect we may still make changes to the API.

I recall looking through your library, and thought I'd responded; I'll check later to see if I can find my notes.

---

Originally posted by @weierophinney at zendframework/zend-expressive-session#1 (comment)

[weierophinney]

First, I see a number of similarities in what we're doing. For instance:

• Our SessionInterface maps pretty closely to your StorageInterface.
• Our SessionPersistenceInterface has similar responsibilities to the combination of your SessionManagerInterface and HandlerInterface.

There are a few key differences.

First, we only pass the session itself as a request attribute, not the "manager" or "persistence". We feel that users generally should not work directly with these aspects, as they can lead to potentially conflicting state and/or overwriting.

Second, and related, we handle regeneration as a flag + persistence operation, vs. solely as a "manager" operation. This is done to ensure multiple regenerations are not invoked, potentially leading to conflicting session cookies. This also allows us to bind a single Session instance to an identifier; calling regenerate() leads to a new instance. Any changes to the old instance are then ignored going forward. (We handle this for the user by decorating the Session instance in what's called a LazySession, which internally replaces its instance with the results of regenerate()).

Third, we merge the "manager" and "handler" responsibilities into a single interface, with only two responsibilities: initializing the session, and persisting it. This approach essentially allows us to be flexible in what we consider "persistence". For instance, with JWT, you would not actually "persist" anything; instead, you parse incoming data from a cookie, and send session data to the user via a response cookie, never storing anything within any application persistence layers. With our proposed interface, this becomes a first-class approach to how sessions are implemented, vs something that has to be coded separately. It also opens the possibility of other approaches we haven't thought up yet!

All things told, I think our two approaches are fairly compatible. There are just a few key design decisions between how we each approach persistence (ext-session-influenced, vs. open-ended).

---

Originally posted by @weierophinney at zendframework/zend-expressive-session#1 (comment)

[ojhaujjwal]

thanks for the perfect explanation. the issue can be closed.