On 04/28/2014 04:05 PM, Jonathan Vanasco wrote:
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`
OK, these drivers did not actually implement ISession then.
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.
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. 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.
In the meantime, AFAICT, it's reasonably simple to put a random id (or
something composed with values unique to the originating request, e.g.
'%s-%s' % (id(request), time.time()) or something) as a value in the
session dict. This would make the application run under any sessioning
implementation. This makes a lot more sense to me than having two
separate ISession interfaces, one with an outside-the-session id, and
one without.
If you're saying that two different applications written by two people
that are unaware of each other need access to the *same* session id
value, then, yes, this doesn't work, unless it's just by a-priori
agreed-upon convention. But I am having trouble envisioning one
application relying on another's use of the same session value to
represent an "id". Can you describe a case for this? Note that I don't
mean two applications that *you* write, because of course you can use a
convention for that, but two applications that must work together that
are written by two totally separate people who have never met each other
or had an opportunity to agree on a shared key name.
- 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 [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.
