On Thursday, May 8, 2014 1:40:58 PM UTC-4, Chris McDonough wrote: > > I'd be surprised. That'd presume the two implementations stored data in > the exact same way, which might well be the case, but can't be assumed. > If it didn't break, it'd only be by happy accident. >
agreed. most just pickle a dict. a few wrap the dict in something. but most just pickle a dict and have internal '__' prefixed fields > The other topic, at this point, is making it possible to uniformly parse > the session id out of the session cookie? > For the sake of clarity: - The other topic is to tie the "session's cookie" to the "session object" itself. - This would have the benefit of *potentially* making it possible to parse the session_id out of the cookie. That would take additional development effort by the end consumer, as different session schemes encode the session id in a cookie differently. Depending on the scheme, this might not be easy/possible. - This would not be as convenient as being able to access a session_id, but it would allow for actual sessions to be identified and trackable and provide for accountability in testing. - This would remove the "black box magic" of the current API, where it is impossible to accurately tell where / how a session was created. I'm still not sure how that would actually help you as much as you think > it would, given that if you change the session implementation, you will > already necessarily need to change code, or at least there's no > guarantee that things will "just work" when you swap in a random session > implementation given your description of the cases you want to support. In the meantime, I'm pretty loath to make "interface suggestions": APIs > are really where the rubber meets the road. It's either in the > interface or it's not, and I'm leaning towards not. > I get that. And I don't expect to sway you on this. But this is where Mike and I bring up that pesky point that all server side sessions feature this... somehow. Without any guidance, they're implemented differently. The needs to access this id may be specialized, but are common enough. Instead of standardizing how a common feature / implementation detail takes place, things are left to be wild. The "Pro" of supporting an official API point is that developers would have guidance and something to write upon. There would be some sort of consistency that leads to higher interoperability. The "Cons" seem to be focus on: - Potential issues/constraints that future session developers might encounter - The potential to return "None" (or raise a NotImplementedError) if an application developer accesses this in an unsupported environment. The first argument is very weak to me, especially on the benefit. It seems be a theoretical issue, not a practical one. I still simply don't understand any use cases where the second argument would actually be a problem. That wouldn't be much different from someone trying to commit a transaction in a transactionless environment. That doesn't mean that you are out of luck, though. Have you thought of > this? It would require that you change code when you change session > implementations, but you already have to do that anyway. > i think we used a NewRequest subscriber to map a session_id attribute onto the session. I'd have to dig into code. we run `request.session` and `request.session_https` ; this allows https calls to read/set the non-https session data. a client side cookie would never interact with a session_id, so that functionality is not needed. Also, the biggest problem of your approach -- and mine -- isn't that I need to update my code. It's that I need to go through all of the session plugin's code to figure out how the key is being managed. i end up reinventing the wheel a lot on this; as does mike. i'm sure others do too. instead of doing all these one-off fixes, i'd rather fork the plugin, make it compatible with an API option and then issue a pull request so others can enjoy benefit of my work. -- 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 pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
