On 04/30/2014 04:36 PM, Michael Merickel wrote:
On Wed, Apr 30, 2014 at 3:28 PM, Chris McDonough <chr...@plope.com <mailto:chr...@plope.com>> wrote:The presumption that there is a session.id <http://session.id> variable won't solve this particular problem, as Bert and Mike have already said. But as a separate problem, it could be "solved" if we mandated that a session id be made available in a common way in the cookie that represents the session token across all implementations. This is a big ask, though, if only because it means that folks who don't actually want to expose the raw session id could not create an interface-compliant implementation. In my experience, it also generally makes systems less flexible when you begin to tell potential implementers how they must do things rather than only telling them what they must do. We also shouldn't forget that sessions do not require a cookie, even if that's the primary way of tracking them across requests. For Pyramid to dictate how a session must be tracked would be a huge loss in the flexibility of the API. Currently the factory has access to the entire request to decide where the session id is at, allowing implementers to do what they need to do to find the tracker from a cookie or a query string or some higher-level mechanism.
Good point. - 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.
