On Saturday, May 3, 2014 7:02:46 AM UTC-4, Chris McDonough wrote: > > Sure. It's always a tradeoff, though. If we over-specify the session > interface, it makes session implementers' lives harder, and may reduce > flexibility for consumers. >
I agree there is a tradeoff, but I don't see how adding a specification of the sort that "If there is a session_id, it should be provided by this method : " is something that necessarily makes lives harder or reduces flexibility. I think it could be the opposite . Different frameworks, packages and plugins handle the concept of a session_id for server-side-sessions in vastly different means. With a dedicated API method, if a plugin writer wants to expose a 'session_id' , they won't have to search and find a name for the method. They'll have a method name and a snippet of documentation to work with. Keep in mind that server-side-sessions are still very popular, and they all require some sort of "session_id" in the backend. It's entirely possible that creating a session_id could be a complex process that requires collision checking against a datastore and/or other methods; looking at how most of the popular sessioning packages are set up though, they all see to follow a loose pattern where the session_id is loaded/generated on instantiation of the session object. I'm also not primarily concerned with requiring package maintainers to integrate session_ids; just recommend that they do, and if they do... there should be a consistent API. I think within a short amount of time, developers who wanted/needed to access the session_ids would build in the needed functionality and issue pull requests. if a developer doesn't provide an id, then that package may be forked or replaced by a similar backend that does. I'll table talking about that "other topic" directly, but want to bring up this indirect point that hits both : Throughout the bulk of pyramid, there are clearly defined APIs to integrate other packages against. one can get to the underlying data / methods / etc in clear and consistent means. this is a significantly different approach than projects like Rails or Django, which isolate the 'consumer' from the underpinnings and rely on "magic" to expose on a selection of data. it's for this reason that many people prefer pyramid. If you don't mind, for clarity, I want to use the term "session_key" instead of "session_id" and "UUID" for the "internal id" for a bit... I don't want to create confusion between the UUID, session_key and python's id().... which are all similarly named. I appreciate the docs suggestion about generating a "UUID" within the session, which can be used for logging and other means. I think that's a great way to handle "session ids" in the sense of a session being an "application user". I'm still concerned ( and I think mike is too ) with being able to access the underlying session object's "key". there are a large common set of use-cases and utilities that a sessions's "UUIID" and "key" can both fulfill. there are numerous advantages that your approach has over using a raw "key" as well. I don't mean to discount any of them. I should, actually, rewrite some parts of our code to use them instead. however, an internal "UUID" is still an alternative to having a consistent API that offers access to the key of the session object. that "key" is still something that all server-side-sessions require by design; and that all packages provide differently. regardless of the reasons that people need to use it or the alternative options that could provide much of the same functionality, without an API endpoint that developers could correlate this data to... this "session_key" becomes a "magic" element and a bit of an advanced topic to people who develop on Pyramid. -- 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.
