On 05/03/2014 12:03 PM, Mike Orr wrote:
On Mon, Apr 28, 2014 at 10:03 PM, Chris McDonough <[email protected]> wrote:
On 04/28/2014 11:28 PM, Mike Orr wrote:
On Mon, Apr 28, 2014 at 3:07 PM, Chris McDonough <[email protected]> wrote:
On 04/28/2014 04:05 PM, Jonathan Vanasco wrote:
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.
We don't need two interfaces. We just need an interface that says
'session.id' or 'session.get_session_id()' should return the session
ID string, or None if it doesn't support session IDs or doesn't wish
to expose it. Presto, everybody's problem is solved.
FWIW, I'd consider this problem created rather than solved in a scenario
that I'd like to support. I create applications that are themselves
frameworks (e.g. substanced). These applications rely on being able to let
deployers of those applications (note: these are not necessarily the same
people as the developers of all the various parts of the application)
configure in different sessioning implementations based on their deployment
requirements. For example, some systems are deployed across multiple app
servers, and the deployer may therefore need to use cookie-based sessions or
a shared backend session store to make sure the same session data can be
read by all of the appservers. These applications also, in the meantime,
allow pluggability of add-ons written by unrelated people.
In this scenario, what happens when someone writes an add-on that (just
because it's available) uses the session id as a key into something, and the
deployer uses this add-on, and the session implementation the deployer has
configured in returns None from get_session_id? Nothing good, AFAICT.
What's the add-on code meant to do in this circumstance? Either the add-on
has to check for None as a return value from get_session_id, or it has to
check that the current sessioning implementation implements the interface
that supports a non-None return value from get_session_id. And what if it
does return None? What's the add-in meant to do?
In my case it's fine because it just stores the None in the access
record. That loses the individual sessions, but at least some of the
others have session IDs so I can measure their behavior. That's better
than having no sessions at all, in which case I can't measure
anything.
There may be cases that break if there's ever a None, but (1) it's the
sysadmin's responsibility to choose a backend that has session IDs,
and (2) we haven't found any use cases for this, whereas my logging
and Jonathan's testing are actual use cases.
So all we're talking about is defining a place for the session ID if
it exists, not saying it's required. There could even be a
'has_session_ids' constant if you want to know whether the current
backend supports it. That could allow you to raise an exception on
startup if it's using the wrong backend.
You haven't found a need to support any use cases similar to the one I
describe above where there's at least three separate individuals
involved (the application developer, the add-on developer, and the
deployer) who all must be able to rely on a shared understanding of the
ISession spec for the system to work ok when they combine their work.
That's fair enough, and I see your point, which is, I believe:
It's maximally convenient for me to be able to rely on a session.id
attribute: I need it for logging, and it's a hassle to need to define
this get_session_id function and use it instead of session.id:
def get_session_id(session):
return session.setdefault('myapp.sid', uuid4())
Also, it's a hassle for new Pyramid users to know that they'll
have to define such a function if they want to be able to rely
on a per-session key. They're used to systems which supply
an id for them already.
I think, however, that you haven't found any need to support this use
case because you in your environment you always wear all three hats (app
developer/add-on developer/deployer).
If I change the ISession spec to require an ID, or to require that some
API return a valid session id or None, it will probably make your life
easier, and probably will make easier the life of the new Pyramid user
in a similar development situation.
However, it will make the life of each person who only wears one of the
hats I describe harder. It will make the ISession implementer's life
harder because he will have to supply a new API even if his
implementation does not need IDs, and older versions of his ISession
code will not be in compliance anymore. It will make the add-on
developer's life harder because she'll have to be aware that session.id
might be None, and when it is, the code may need to branch out to
something similar to the function I showed above, or she might decide to
just use that function always. It will make the deployer's life harder
because he may wind up trying to combine an add-on and an ISession
implementation that don't really work together due to confusion on the
part of one or the other.
In the meantime, since you control the horizontal and vertical, and
you're most often wearing all three hats, it's pretty easy for you to
write the above function and use it. I think you're doing that now
without any ill effect. You've already borne the cost of the pain, and
now you're arguing with the umpire on the behalf of new users, more or
less, right?
We could mandate session.id. But instead of adding session.id, we could
alternately make the situation for the new Pyramid user better by adding
something to the docs about the ISession API not having an id, describe
the "why", and show the snippet function above to let them know how to
get around it.
So I guess my argument for not necessarily requiring session.id is that
there are other ways to make it better for the new Pyramid user that
don't impose the burden described above on ISession/add-on developers
and deployers by placing a small docs-reading burden on the person who
might wear all three hats.
Does that make sense? Note that I really am trying to get to the heart
of this issue, not trying to be obstinate, just trying to make my point
understood.
- 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.
