On 05/08/2014 01:05 PM, Jonathan Vanasco wrote:
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.
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.
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.
The other topic, at this point, is making it possible to uniformly parse
the session id out of the session cookie?
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.
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.
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.
# in my_package
from pyramid_redis_sessions import RedisSessionFactory
from pyramid.session import SignedCookieSessionFactory
def my_session_factory(**settings):
cookie_session_factory = SignedCookieSessionFactory(**settings)
redis_session_factory = RedisSessionFactory(**settings)
def session_factory(request):
if request.scheme == 'http':
session = cookie_session_factory(request)
session.id = None
else:
session = redis_session_factory(request)
session.id = session.session_id
return session
return session_factory
# in configuration code
from my_package import my_session_factory
settings = {...}
config.set_session_factory(my_session_factory(**settings))
<Some massaging required to pass "the right" settings to each factory
you're delegating to left out....>
This would give you a single place to make any changes necessary to the
session before returning it. You would effectively be reusing existing
session factory implementations and massaging the result of each to
provide a locally defined session interface. Composition is magic when
applied this way.
- C
--
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.
