Hi Paul, Thanks for writing back.
I actually presented this idea on the discord channel about a year ago first, and at the time people expressed interest, just this week people on discord channel it was brought up by somebody else. In a PHP chat channel of 6,000 members , I frequently come across the problem where people want or need to switch out the framework session library for one reason or another, e.g they want to start using swoole or they companies want to decouple their code from the frameworks that they are using, having a PSR for sessions, makes swapping out stuff every easy. Also in this day and age companies are using multiple frameworks for their projects, in most cases those projects work with sessions, and it would be nice if we did not have to learn all the different session libraries for each framework. Furthermore, in most PHP frameworks including symfony and even frameworks in other languages such as java ( https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html) , they all have a getSession method, as this is part of the request. So having a standard for sessions to complete the existing PSRs is another reason. Also what is the point of learning how to use a PSR request or response object then you pull a different session object from it each time, we all look for the session object there now. I actually had the idea when writing a integration testing suite for applications that use the PSRs, its gets messy when working with sessions because there is no standard way, there are standard requests, standard responses, standard request handling, but no standard for storing data between requests, and PHP sessions dont work nicely with PSR 7 response objects, so by having a standard we dont need to worry about that anymore. Amanda. On Thu, 29 Sept 2022 at 20:11, Paul Dragoonis <dragoo...@gmail.com> wrote: > Hi Amanda, > > Ask yourself. What problem in the community are you solving? > > We don't want to make standards for the sake of it. > > Are people actively trying to write code in Symfony that doesn't wanna use > Symfony sessions? > > Figure out the demand first, validate it, present some info. > > I'm not a blocker here in this process, I'm just asking you to have a > think. > > When we started this group (fig) we were wanting to make standards for all > sorts of things, including sessions, but after we done the market analysis > we realised the masses were not really interested in adopting a generic > session standard. > > If the appetite has changed, then let's do it. > > Food for thought. > > Cheers, > Paul > > On Thu, 29 Sep 2022, 18:32 Larry Garfield, <la...@garfieldtech.com> wrote: > >> On Thu, Sep 29, 2022, at 3:14 AM, Amanda wrote: >> > Thanks for your interest, I also agree that the PHP community needs >> > this very much. >> > >> > The code in my proposal is an example and proof that we can make >> > everything work together. >> > >> > The purpose of the working group is to come up with a solution together >> > that can be used by everybody. >> > >> > Once a working group has been formed (and we have a sponsor), a >> > detailed proposal will be written, then the working group would start >> > from a blank canvas >> > as it would be clearer then what will be covered and what won't in this >> > PSR. >> > >> > Does anybody know if we need a sponsor to form the working group, or do >> > we need to form the working group to get the sponsor, it is not clear. >> > >> > Ideally I was hoping for representatives from other frameworks to be >> > part of this working group, anybody here? >> > >> > Amanda >> >> The formal formation of a working group includes "here's the basic >> skeleton of a PSR and what it hopes to do, here's the members of the >> working group including a Sponsor, Core Committee please vote to charter >> us." >> >> So a Sponsor is needed prior to the Entrance Vote. >> >> --Larry Garfield >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to php-fig+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/7e8a2e90-efe7-4900-b7f6-d221fd7b2607%40app.fastmail.com >> . >> > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAKxcST9B5Rp-tK_q4e7-45nhvO1qcyiBVQTqsjhsTTgJqjCVKw%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAKxcST9B5Rp-tK_q4e7-45nhvO1qcyiBVQTqsjhsTTgJqjCVKw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAP2uk-B8tF51QgYMjMkOFYbxzFXR20Bqs_%2BR%3DKP31kKrohygDg%40mail.gmail.com.
