On Thursday, May 8, 2014 7:16:43 AM UTC-4, Chris McDonough wrote: > > All of the above use cases presume that you have visibility into the > session implementation's backend to load data. If you do, that's fine, > but there are no APIs in Pyramid that provide this functionality, so > you're already in implementation-dependent mode when trying to satisfy > any of them.
Agreed. I'm not trying to use this data to do anything "with" the Pyramid system. Having the ability to uniformly access a session's id > across ISession implementations buys you very little in these cases, > because you're already relying on implementation details that > necessarily go behind the back of ISession. You couldn't just swap out > one sessioning implementation for another, and expect these kinds of > tests or features to continue working, even if ISession did have an ID > API, right? > Yes and No. Incompatible: If I were switching out a Redis for a Memcached system, then I'd need to have tests that can adapt the "loading" mechanism or are specific to whatever is active. Compatible: If I were switching between two Redis or two Memcached backends, then everything should work. > Server-side sessions are usually quite expensive. Personally I use them > very sparingly. Unleash "ab" against a page that accesses session data > and see. Definitely if all I needed was some tracking identifier, I'd > use a plain old cookie, if only to reduce CPU cycles on the server side. Agreed. That's why we use 2 sessions -- encrypted cookie on http ; server side on https -- and that's why we've switched backends a bunch, trying to edge out a little bit more performance. Our https session data has data in it that we don't want to expose publicly (even in encrypted form) and is expensive/large to load. So it's more efficient in this case. In any case, without an actual in-the-wild use description of a required > feature that does not presume visibility into the session data backing > store or being able to parse the session id value out of a cookie, I'm > becoming more convinced that not requiring that an ISession implementer > expose the session id uniformly is actually correct. That doesn't mean > that session implementations can't expose it; pyramid_redis_session > sessions already expose the session id (as session.session_id, FWIW), so > you could rely on this implementation detail as easily as you're already > relying on the detail (at least if you use pyramid_redis_sessions) that > session data gets stored in redis. Relying on this would be no worse > than writing integration tests that check redis to see if the data > actually winds up there. > Being an implementation detail is fine and fair. As I said before, I'm more concerned with the other topic, which would also handle any of my needs. I still would really like to see a "Recommended Practice" in the docs so that, if another person builds a session plugin and decides to expose this data, it would be the same as pyramid_redis_session or something else. -- 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.
