On Sunday, October 2, 2022 at 9:08:30 AM UTC-4 amanda...@gmail.com wrote: > Vince, > > Firstly, I don't think it was correct or professional of you to submit a > separate proposal for PHP sessions without me to the PHP fig repo, > basically sidestepping and ignoring my work and effort, i feel this was > really disrespectful. > > Secondly, I believe the CC members want to see interest and buy in from > other frameworks. > > IMHO. Looking at your submission think are too many interfaces and the > session interface is way too polluted for a PSR (e.g. getIssuedAt getRepo, > setRepo, resume, migrate etc) and very it limiting for anybody who wants to > implement it, it removes the freedom from the frameworks to do their own > thing,restricting design and creativity without offering much benefit, it's > basically looks like a set of interfaces from a library and therefore you > would be enforcing a library design. This is not a PSR is about. > > As a framework writer I would not like this, and I don't think the PSR > should cover the backend. If the session interface is attached to a handler > by design and people drop that in, then so be it - same as PSR log, that is > the beauty of the PSRs. > > If you take a look at the PSRs you will see and appreciate the beauty in > the simplicity. > > My submission to this group was based on the idea to try and gather > interest from other parties to get backing, discussing design here is > irrelevant, this must be done by the working group when formed, that is > what a working group is for. My proposal was based upon the minimum > requirements that I think needs to be covered by the PSR (and some things > which i think are cool standarding session cookie name and token etc), but > only once a working group can be formed and agreement can be made on what > problems are being solved and what will be covered and what not then the > interfaces can be designed properly. > > Amanda > > On Sun, 2 Oct 2022 at 11:38, Vinnie Marone <vinnie....@gmail.com> wrote: > >> On Friday, September 30, 2022 at 4:26:37 AM UTC-4 amanda...@gmail.com >> wrote: >> >>> Paul, >>> >>> The chat I was referring to is the PHP slack channel, it has 6k members >>> but it is not as active as it was before covid. >>> I think the symfony slack channel has 21k members and larachat channel >>> claims to have 36k members. >>> >>> Amanda >>> >>> On Thu, 29 Sept 2022 at 22:31, Paul Dragoonis <drag...@gmail.com> wrote: >>> >>>> >>>> >>>> On Thu, 29 Sep 2022, 20:51 Amanda, <amanda...@gmail.com> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thanks for writing back. >>>>> >>>> >>>> Hi Amanda, >>>> >>>> Good reply! >>>> >>>> Which chat room has 6000 people ? >>>> >>>> Maybe dont couple it to PSR-7 tho. >>>> >>>> That means people have to use and adopt 2 standards to use 1. Keep it >>>> independent. >>>> >>>> We thought about this before, and we realised this wasnt the best idea. >>>> >>>> Keep up the energy 💪 looking forward to seeing the progress. >>>> >>>> Many thanks, >>>> Paul >>>> >>>> >>>> >>>> >>>>> 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 <drag...@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+u...@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+u...@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+u...@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 >>>>> >>>>> <https://groups.google.com/d/msgid/php-fig/CAP2uk-B8tF51QgYMjMkOFYbxzFXR20Bqs_%2BR%3DKP31kKrohygDg%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+u...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/php-fig/CAKxcST9EuECoeoVeHdOK5twgotB7toamvgEchbHj96psw17OxQ%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/php-fig/CAKxcST9EuECoeoVeHdOK5twgotB7toamvgEchbHj96psw17OxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >> >> Hey all, >> >> I feel coupling the interface alone to a PSR7 implementation would defeat >> the overall purpose of this. My original intention when I had brought this >> up last week which led to this conversation being started again, was the >> fact that working with sessions and testing in php is not entirely great >> since it emits headers (yes there are options to turn these off before you >> start the session). But that doesn't stop the fact that it is a clunky mess >> as it forces developers to have to use $_SESSION(in some capacity, even if >> you just wrap it in a singleton) which depending on who you ask is fine or >> isn't as they hate globals. >> >> What I find cool about removing it from the global state entirely is that >> a developer now has the flexibility to query multiple sessions with ease of >> instantiating a new object. Not sure why anyone would wanna do that but >> again it gives them the flexibility to do so easily. >> >> I think the psr should stand alone. Do 1 thing and 1 thing alone. Manage >> a session implementation that does not emit any headers. Leave this up to >> the libraries and or developers on how to do that. >> >> Obviously if you do that and make it independent as paul is suggesting. >> It not only allows someone to make the decision to use a PSR7 >> implementation or use something else entirely. >> >> I've added a rough draft with more functions and more interfaces. >> Decoupling the SessionInterface away from the storage engine that would be >> used. >> >> >> https://github.com/Porthorian/fig-standards/blob/master/proposed/session.md >> >> Vinnie >> >> -- >> 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+u...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/c2f15154-f8bf-439d-95fa-07042955d3c3n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/c2f15154-f8bf-439d-95fa-07042955d3c3n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >
Hello Amanda, I am sorry you feel that way and apologies for any sort of disrespect you may have felt. However, I would like to clarify a few things. I did not submit a pull request to the PHP-FIG repository. I simply forked it and created the README.md so I could add it to this email list. It is my mistake that I assumed this was where we would discuss designs of our vision of how PHP sessions would be handled. For that I am sorry. With that out of the way. I think we should now start discussing moving more towards a working group rather than critiquing individual proposals in detail. Any future proposals or design talk without a working group is more of a moot point. For that I apologies for bringing us down this road. But the discussion does need to move towards a working group. To that end, I have reached out to Taylor Otwell from Laravel and Nicolas Grekas from Symfony. To see if they are interested in seeing a PSR session standardization across PHP. If either of them decide that it is not worth their companies time. Then this will not even make it to a working group. Vinnie -- 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/38308af1-c616-479b-adb3-2068edaf14bbn%40googlegroups.com.
