On 04/28/2014 11:04 AM, Jonathan Vanasco wrote:
1. Like I mentioned above, but not very clearly, the big reason why I
dislike the pyramid_session_[foo] approach, is that the only
standardization is how it adapts to the ISession interface. There's no
standardization on the (de)serialization interface. With the Beaker
model, almost everything is the same -- if you switch backend storage,
you don't run into any surprises. There's also a general
standardization on the configuration settings. You can swap between
backends easily and without surprise.
With the pyramid_session_[foo] approach, although the developer
interface is similar, under-the-hood it's quite different. We ran into
issues while testing with how objects were able to be (de)serialized ,
and switching from one backend to another meant needing an entirely
different approach for configuration. if you're willing to buy-in to a
single sessioning package for good, it's fine. If you need to run
different packages in different environments, or might change in the
future, it's a hassle.
There actually is standardization on serialization and deserialization.
The ISession interface docstring:
class ISession(IDict):
""" An interface representing a session (a web session object,
usually accessed via ``request.session``.
Keys and values of a session must be pickleable.
"""
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?
2. I still really think that ISession should support an official
`session_id` attribute
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.
3. chris- buildout is great. i've used it many times. but as you deal
with larger and more varied organizations, it loses it's utility as "The
Solution". if everyone involved in a project is decently versed in
Python and has some backend knowledge -- great. But once you start
adding in dedicated HTML/CSS/JS people or graphic designers who need to
update assets and can barely use a GUI version tracking app... you end
spending all the savings in "setup" on troubleshooting individual
people's machines. being able to run the app with as few services as
possible is , in a word, "heavenly".
Yeah, I dunno. We use buildout quite often to deliver a locally-running
system to nontechnical users and graphic designers. But we're also
committed to making sure that we build most everything from source when
it matters (e.g. sometimes redis, postgres, etc), so over time it
becomes less and less likely that the build won't work. I realize this
is a committment that not everyone is willing to make.
- 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.
