Ian Bicking wrote:
> Same location:
>
> http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
BTW, session stores aren't really what I'm focused on at the moment. I
just thought I'd be helpful moving the discussion forward past general
requirements to something easier to discuss,
Mike Orr wrote:
>> The session manager id is used by the session store, to keep the
>> sessions separate. Actual session data is keyed by
>> (session_manager_id, session_id), so that separate applications have
>> separate session_manager_ids, and separate browsers have separate
>> session_ids.
Ian Bicking wrote:
> Mike Orr wrote:
> I don't think several frameworks should share a single SessionManager
> *instance*.
Isn't that what being a session manager means? The single gateway to
the stores. Otherwise it's more a case of two instances co-managing.
That sounds more difficult
Rene Dudfield wrote:
>>>* Scenario 4: Two apps in different virtual hosts.
>>
>>Probably not an issue because the session id won't be shared. A good
>>session id manager might be able to handle this, though, but forwarding
>>the user between the two hosts with a special GET variable that triggers
Looks quite good. It should be able to handle all the uses I have for
sessions. I am sure it will change a little once it is started to be
implemented.
> > * Scenario 2: Same, but the apps are in separate processes. The
> > dispatcher remains. (forking servers)
>
> If the two apps share the s
Mike Orr wrote:
> Ian Bicking wrote:
>
>> Same location:
>>
>> http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
>>
>>
>
>
> Good work.
>
>
>> This version separates out SessionManager from SessionStore, and
>> suggests that managers be per-application (or maybe per-framewo
Ian Bicking wrote:
>Same location:
>
>http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
>
>
Good work.
>This version separates out SessionManager from SessionStore, and
>suggests that managers be per-application (or maybe per-framework).
>
There's per-application/per-framew
Same location:
http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
This version separates out SessionManager from SessionStore, and
suggests that managers be per-application (or maybe per-framework). I
also expanded docstrings and bunch of other changes. Open questions are
mar
-> Wow! I'm dumbfounded by this whole conversation! I thought session
-> backends were something innane enough that we could agree on them! I
-> have the same use cases as Geoffrey. No, cookies are not a good
-> replacement for sessions since you have to validate them everytime you
-> use them.
Wow! I'm dumbfounded by this whole conversation! I thought session
backends were something innane enough that we could agree on them! I
have the same use cases as Geoffrey. No, cookies are not a good
replacement for sessions since you have to validate them everytime you
use them. You can't tru
Jonathan Ellis said:
>
> Now that's an example of when I think sessions are a poor solution. IMO
> caching objects from the database is the job for the, well, database
> object cache. :)
>
> They are similar but not identical. For instance, while session data
> typically expires after a certain a
Ian Bicking wrote:
>> At minimum, the SessionManager links the SessionStore, Session, and
>> application together. It can be generic, along with
>> loading/saving/locking. (Although we might allow the application to
>> choose a locking policy.)
>
>
> That could be a little difficult, since
FWIW, some interesting ideas (and not so interesting ideas) for
sessioning architecture in general are captured at
http://www.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/UseCases
and
http://www.zope.org/Wikis/DevSite/Projects/CoreSessionTracking/CoreSessionTrackingDiscussion
UML that mo
Mike Orr wrote:
>Regarding sessionless persistence, that reminds me of a disagreement I
>had with Titus in designing session2. Quixote provides Session.user
>default None, but doesn't define what other values it can have. I put a
>full-fledged User object with username/group/permission info.
Mike Orr wrote:
> Regarding Ian's session interface:
> http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
>
> Ian Bicking wrote:
>
>> Thinking on it more, probably a good place to start would be agreeing
>> on specific terminology for the objects involved, since I've seen
>> sev
Regarding Ian's session interface:
http://svn.colorstudy.com/home/ianb/scarecrow_session_interface.py
Ian Bicking wrote:
>Thinking on it more, probably a good place to start would be agreeing on
>specific terminology for the objects involved, since I've seen several
>different sets of terminolo
I haven't been closely following this thread and this may have already
been said but IMO sessions are most useful when the querying user is not
identified and you need a place to stash data related to that user (e.g.
a shopping cart). They are convenient in other cirumstances but rarely
necessary.
Anyone still interested in session libraries? Putting the wisdom of
such a thing aside, any thoughts on a library itself?
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://w
At 05:06 PM 8/16/2005 -0400, mike bayer wrote:
>theres also security considerations regarding using only cookies without
>server side sessions. For login tokens, if theres no corresponding
>server-side token to match up that it is in fact a current login and not
>something left over from a long-cl
At 05:08 PM 8/16/2005 -0400, Geoffrey Talvola wrote:
>Jonathan Ellis wrote:
> > Still, it can be good to have a simple place to store non-permanent
> > information.
>
>For example...
>
>I think a good use of sessions is in remembering selections that have been
>made earlier on. For example, suppos
On Tue, 16 Aug 2005 17:06:57 -0400 (EDT), "mike bayer"
<[EMAIL PROTECTED]> said:
> I also
> think server-side sessions are an easy place to store user preferences
> and
> permissioning information originally loaded from the database, as a quick
> and easy way to cut down on repeated database calls
Jonathan Ellis wrote:
> Still, it can be good to have a simple place to store non-permanent
> information.
For example...
I think a good use of sessions is in remembering selections that have been
made earlier on. For example, suppose you have a reporting application
where you allow the user to
Phillip J. Eby said:
> I agree; and in fact until I saw Ian's status-message example, I've never
> had need to store anything in a cookie except login credentials or an
> identifier used to find application objects like a shopping cart.
>
> IOW, cookies are fundamentally for short strings. Howeve
On Tue, 16 Aug 2005 16:37:31 -0400, "Phillip J. Eby"
<[EMAIL PROTECTED]> said:
> At 01:14 PM 8/16/2005 -0700, Jonathan Ellis wrote:
> >But there's a reason they're in such common use; it's a huge waste
> >(particular for low-bandwidth clients) to store anything more than
> >absolutely necessary in
At 01:07 PM 8/16/2005 -0700, Robert Brewer wrote:
>Phillip J. Eby wrote:
> > To put it another way, I see an opportunity here to
> > educate developers about better ways of doing things,
>
>I (and some of the other CherryPy devs) agree that there are better
>ways, particularly when using a persiste
At 01:14 PM 8/16/2005 -0700, Jonathan Ellis wrote:
>Sure, sessions are overused and abused. Particularly among certain
>classes of developers which I won't characterize here. :)
>
>But there's a reason they're in such common use; it's a huge waste
>(particular for low-bandwidth clients) to store a
On Tue, 16 Aug 2005 15:45:47 -0400, "Phillip J. Eby"
<[EMAIL PROTECTED]> said:
> >I'm not sure; I always try to make the cookie last longer than the session
> >can. I suppose you could store information about when the cookie is
> >supposed to expire in the session itself (since you can't read ex
Phillip J. Eby wrote:
> To put it another way, I see an opportunity here to
> educate developers about better ways of doing things,
I (and some of the other CherryPy devs) agree that there are better
ways, particularly when using a persistent server process.
> ...rather than to institutionalize w
At 12:46 PM 8/16/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>SessionManager is responsible for expiration. I'm not sure what you are
>>>thinking of for refresh. Updating last-accessed time? That would be
>>>the SessionManager as well.
>>
>>By refresh, I mean updating a cookie's ex
Phillip J. Eby wrote:
>> SessionManager is responsible for expiration. I'm not sure what you
>> are thinking of for refresh. Updating last-accessed time? That would
>> be the SessionManager as well.
>
>
> By refresh, I mean updating a cookie's expiration time.
I'm not sure; I always try to
At 12:02 PM 8/16/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>Session:
>>>An instance of this represents one user/browser's session.
>>>SessionStore:
>>>An instance of this represents the persistence mechanism. This
>>>is a functional component, not embodying any policy.
>>
Phillip J. Eby wrote:
>> Session:
>>An instance of this represents one user/browser's session.
>> SessionStore:
>>An instance of this represents the persistence mechanism. This
>>is a functional component, not embodying any policy.
>> SessionManager:
>>This is a container for sessi
At 11:28 AM 8/16/2005 -0500, Ian Bicking wrote:
>I wrote a possible interface for sessions:
>http://aspn.activestate.com/ASPN/CodeDoc/Apache-mod_perl_guide/src/modules.html
Um, wha?
>Session:
>An instance of this represents one user/browser's session.
>SessionStore:
>An instance of this
Robert Brewer wrote:
>>I wrote a possible interface for sessions:
>>
>
> http://aspn.activestate.com/ASPN/CodeDoc/Apache-mod_perl_guide/src/modul
> es.html
>
> You wrote Apache::Session, ::DBI, ::Request, AND ::SubProcess? I must
> remember to put that in my memoirs...
Doh! Clearly my copy-and
I wrote a possible interface for sessions:
http://aspn.activestate.com/ASPN/CodeDoc/Apache-mod_perl_guide/src/modules.html
It's not my most thoughtful effort, but maybe it can be a discussion
point. Feel free to offer completely different APIs if you think this
one sucks. I basically just thr
35 matches
Mail list logo
