On Monday, April 28, 2014 1:11:17 PM UTC-4, Chris McDonough wrote: > > As the class docstring indicates, the only contstraints on keys and > values are that they must be pickleable. If some sessioning > implementation does not provide this feature, it doesn't meet the > ISession interface (which doesn't mean it's not useful, it just means > it's not really in compliance). This would be a bug in an > implementation that aims to provide compliance. Were you running into > something that could not be pickled, or? >
I don't remember what we were using, but some of the backend drivers we had at one point weren't using `Pickle` The reason there isn't a "session_id" API is because not all sessions > have an ID. For example, the cookie session stuff in the core doesn't > have (nor need) an ID, because there's no storage to need to look the ID > up in to retrieve the session data. Meanwhile, it's pretty simple to > put a random value into the session to act as an application-specific > ID. That's the rationale anyway. > i strongly disagree with the rationale. 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. Yeah, I dunno. We use buildout quite often to deliver a locally-running > system to nontechnical users and graphic designers. But we're also > committed to making sure that we build most everything from source when > it matters (e.g. sometimes redis, postgres, etc), so over time it > becomes less and less likely that the build won't work. I realize this > is a committment that not everyone is willing to make. > That's a commitment everyone I know would love to make, but can't afford the resources to act on. -- 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.
