On Mon, Apr 28, 2014 at 3:07 PM, Chris McDonough <[email protected]> wrote: > On 04/28/2014 04:05 PM, Jonathan Vanasco wrote: >> > IMO, the point of an interface is to provide an abstract API which folks can > meet to provide alternate implementations. If server-side session > implementations had a session id, but client-side session implementations > did not, it would mean that *deployers* of an application could not switch > out the sessioning implementation from one to the other and still expect the > parts of their applications which rely on sessions to work, which is AFAICT > exactly what you're objecting to now.
We don't need two interfaces. We just need an interface that says 'session.id' or 'session.get_session_id()' should return the session ID string, or None if it doesn't support session IDs or doesn't wish to expose it. Presto, everybody's problem is solved. > The only difference between this > scenario and the one you're objecting to is that you started relying on > something *outside* the interface, and when you changed to using something > that actually complied with it, you got hosed. I switched from Pylons to Pyramid and got hosed. Pyramid is supposed to be better than Pylons and more flexible, but in this case it's worse and less flexible. The Pyramid interface is less useful than Beaker's. That's a limitation of the Pyramid interface, and can arguably be considered a bug. > In the meantime, AFAICT, it's reasonably simple to put a random id (or > ... in the session > dict. This would make the application run under any sessioning > implementation. That's what I ended up doing, but why not have a standard way to get the session ID? >> client-side sessions don't have an id, but server-side sessions require >> it. because pyramid doesn't have an official interface to support this, >> all server side session libraries need to implement this themselves -- >> somehow -- to support it. I stress "somehow". There's no way to ensure >> or expect consistency in this across libraries. If you look at how >> different session providers in the ecosystem have dealt with this, there >> is little uniformity in approach. I've seen `session_id`, >> `_session_id`, `sessionID` and a few other variations -- both as >> attributes and internal dict values. If ISession had an official >> `session_id` attribute, then people developing server side libraries >> would adapt to that; there would be uniformity and portability. Those >> using client-side sessions would never use or expect a session_id , and >> not be inconvenienced. I *tried* to write a 'pyramid_[session]' library... I *tried* to modify 'pyramid_redis_sessions' to put the ID as 'session.id' or 'session["id"]''... I *tried* to understand how Beaker did it... But every time I got lost in how they generate the ID and manage the cookie. And when I tried to just read the cookie in my tween, I realized I would have to unsign it and get the secret... all the stuff that the session library does, and why should I have to reimplement it all? Why can't the library just have a METHOD that I can CALL? Everything else in Pyramid does. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
