On 05/05/2014 12:10 PM, Jonathan Vanasco wrote:
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.
This conversation seems to be going in circles a bit.
Rather than debating the idea in the abstract, I'm trying to figure out
how you, in particular, would actually concretely make use of
"session.id" (or session.key or whatever).
This question needs to be considered independently from:
- being able to parse the key out of a cookie value "by hand". This
is unrelated to having an API on the session object itself.
Being able to do this is another topic which we need to
consider independently.
- being able to use the key as a lookup value into a sessioning
implementation. There is currently no ISession API to pass the key
to obtain information about the session, and adding such an
API is yet another topic.
Can anyone give me a concrete usage that's not solved by using a UUID
key stored in the session data itself that does not involve the 2
constraints above?
- 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.
